三个新的API已经公布：
Process API在更新后能够与操作系统中非JAVA相关的进程互动，目前使用的API存在诸多限制，这迫使开发人员经常求助于本地代码。这个API存在的主要风险是操作系统的异构性，尤其是Windows。该API的设计需要适应在不同的操作系统上的小型设备的部署工作，它还应该考虑多个Java虚拟机运行在同一个操作系统进程的环境。这些考量将带来一个更为抽象的API，这会增加设计的工作量。
新的HTTP客户端，引入了对HTTP/2的支持。
现有API的问题及实现：
- 基于URLConnection的API是考虑到多种协议而设计的，其中很多都已经被废弃了(ftp, gopher等)
- 早先的HTTP 1.1过于抽象
- 难以使用（许多行为都没有文档化）
- 只能以阻塞模式工作（每个请求/响应对应一个线程）
- 非常难以维护
Https 2.0支持依赖于TLS ALPN (Application Layer Negotiation Extension)，目前JDK中并不支持，Http 2.0规范本身还处于互联网草案的形式，但在2014年它有望成为一个正式草案。
新的轻量级JSON API：它提供了一个轻量级的API用来处理和生成JSON文档以及数据流，后者是基于已经标准化的JSON支持，它是JSR 353的一部分。
还有三个JVM和性能相关的特性公布：
改进竞争锁，旨在改进当线程竞争访问对象时的性能。改进竞争锁对现实世界中的应用程序大有裨益，尤其是针对工业基准，如Volano和DaCapo。
这项工程将在以下与竞争Java监视器相关的领域，探索性能改进：
- 字段重排序(Field reordering)和缓存线对齐(cache line alignment)
- 加速PlatformEvent::unpark()
- 快速的Java监视器操作进入操作
- 快速的Java监视器退出操作
- 快速的Java监视器notify/notifyAll操作
- 自适应的spin改进以及SPARC上的SpinPause
分割JIT编译器的代码缓存（在大型应用程序上获得更好的JIT性能）。将代码缓存分解为独立的段，每个段都包含特定形式的编译代码，目的是为了改善性能，并支持未来扩展。
编译代码的组织和维护会对性能造成巨大影响，如果代码缓存走错了方向，若干方面的性能退化实例将会获悉。在引入多层编译后，代码缓存的地位变得极其重要，因为编译代码的数量比起不使用多层编译，会有2-4倍的增长。多层编译也引入了一个新的编译代码类型：instrumented编译代码 (异型代码)。异形代码具备与非异形代码不同的属性，其中一个重要区别是，异形代码有一个预定义的限制性生命周期，与此相反，非异形代码永远都会保留在代码缓存中。
现存的代码缓存是针对单一代码优化的，即只有一种形式的编译代码。代码缓存被组织为一个独立的堆数据结构，位于一个连续的内存块头部。因此，具有预定义的限制性生命周期的异形代码将与非异形代码混合，并永久保留在代码缓存中，这会带来不用的性能和设计问题。比如说，sweeper方法在扫描时将被迫扫描整个代码缓存，即使其中一些实体从未更新，或存在非方法的代码。
“智慧的”Java编译器的深入开发，称之为sjavac，它支持并行和共享编译，还包含一些其他特性。
由于存在各类关于稳定性和可移植性的问题，sjavac在默认情况下并没有在JDK构建脚本中使用，这项JEP的首个目标是解决这些问题，这牵扯到必须确保工具能始终在所有的软硬件配置上产生可靠的结果。
总体目标是要改善sjavac的质量，使其成为一个通用的javac封装，有能力编译各种大型Java项目。
后续项目将继续探索如何在JDK工具链中将sjavac分离出来，如果可以的话。sjavac可能会成为一个独立支持的工具，或是与javac集成的非独立工具，或是其他。
最后，一个诱人的特性已经在JEP 201中得到了承诺：模块化源码。这其实就是曾经我们熟知的模块化解决方案“Jigsaw项目”（最初目标是Java 8的一部分）。
Jigsaw项目旨在为Java SE平台设计和实现一套标准化的模块系统，并应用于自身平台中，继而投入到JDK中。其最初的目标是使平台实现更容易扩展到小型设备上，改善安全性和可维护性，改善应用程序性能，并提供给开发人员在面对大型应用时一种更好的工具。
这项JEP是Jigsaw项目的第一阶段的一部分，接下来JEP会将JRE和JDK的镜像模块化，之后再引入一个模块系统。
在早期对源代码进行重新组织的动机是：
- 让JDK开发人员有机会熟悉系统的模块化结构。
- 通过在构建中强制模块边界，继续推进结构，这甚至会发生在引入模块系统之前。
- 对Jigsaw项目进行深入开发，而不是总是“慢吞吞地”将现有的非模块化代码转化为模块化代码。