Java 9 – 终极特性列表 已翻译 100%

oschina 投递于 2014/09/13 07:30 (共 11 段, 翻译完成于 09-16)
阅读 52698
收藏 96

This post will be updated with new features targeted at the upcoming Java 9 release (last updated: 9/9/2014)

The OpenJDK development is picking up speed: after the Java 8 launch in March 2014, we’re expecting to enter a 2 year release cycle. Java 9 will reportedly be released in 2016, and an early list of JEPs (JDK Enhancement Proposals) that target the release has already been published. Moreover, some JSRs (Java Specification Requests) are already being worked on and we’ve also added a hint of other features that might be included.

The flagship features are the Jigsaw project, significant performance improvements and long awaited APIs including: Process API updates, JSON as part of java.util and a money handling API. For those of you who want to be on the bleeding edge, JDK 9 early access builds are already available here.

In this post we’ll keep updating around the main new features for Java 9 and what they’re all about. So stay tuned for additional updates!

Table of contents

  1. [Accepted] Project Jigsaw – Modular Source Code

  2. [Accepted] Process API Updates

  3. [Accepted] Light Weight JSON API

  4. [Accepted] Money and Currency API

  5. [Accepted] Improved Contended Locking

  6. [Accepted] Segmented Code Cache

  7. [Accepted] Smart Java Compilation – Phase Two

  8. [Expected] HTTP 2 Client

  9. [Expected] REPL in Java

  10. Where do new features come from?

已有 1 人翻译此段

Accepted features

1. Project Jigsaw – Modular Source Code

Project Jigsaw’s goal is to make Java modular and break the JRE to interoperable components, one of the most hyped features for Java 9. This JEP is the first out of 4 steps towards Jigsaw and will not change the actual structure of the JRE and JDK. The purpose of this step is to reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time. The project was originally intended for Java 8 but was delayed since and retargeted at Java 9.

Once it’s finished, it would allow creating a scaled down runtime Jar (rt.jar) customised to the components a project actually needs. The JDK 7 and JDK 8 rt.jar’s have about 20,000 classes that are part of the JDK even if many of them aren’t really being used in a specific envrionment (although a partial solution is included in the Java 8 compact profiles feature). The motivation behind this is to make Java easily scalable to small computing devices (Internet of Things), improve security and performance, and make it easier for developers to construct and maintain libraries.

More about JEP 201

已有 1 人翻译此段

2. Process API Updates

So far there has been a limited ability for controlling and managing operating system processes with Java. For example, in order to do something as simple as get your process PID today, you would need to either access native code or use some sort of a workaround. More than that, it would require a different implementation for each platform to guarantee you’re getting the right result.

In Java 9, expect the code for retrieving Linux PIDs, that now looks like this:

public static void main(String[] args) throws Exception
    Process proc = Runtime.getRuntime().exec(new String[]{ "/bin/sh", "-c", "echo $PPID" });

    if (proc.waitFor() == 0)
        InputStream in = proc.getInputStream();
        int available = in.available();
        byte[] outputBytes = new byte[available];;
    String pid = new String(outputBytes);

    System.out.println("Your pid is " + pid);

To turn into something like this (that also supports all operating systems):

System.out.println("Your pid is " + Process.getCurrentPid());

The update will extend Java’s ability to to interact with the operating system: New direct methods to handle PIDs, process names and states, and ability to enumerate JVMs and processes and more.

More about JEP 102

已有 1 人翻译此段

3. Light-Weight JSON API

Currently there are alternatives available for handling JSON in Java, what’s unique about this API is that it would be part of the language, lightweight and would use the new capabilities of Java 8. And will be delivered right through java.util (Unlike JSR 353 which uses an external package or other alternatives).

** Code samples coming soon!

More about JEP 198

已有 1 人翻译此段

4. Money and Currency API

After the new Date and Time API introduced in Java 8, Java 9 brings with it a new and official API for representing, transporting, and performing comprehensive calculations with Money and Currency. To find out more about the project, you can visit JavaMoney on Github. Code and usage examples are already available right here . Here are a few highlights:

Money amt1 = Money.of(10.1234556123456789, "USD"); // Money is a BigDecimal
FastMoney amt2 = FastMoney.of(123456789, "USD"); // FastMoney is up to 5 decimal places
Money total = amt1.add(amt2);

The new money types: Money & FastMoney

MonetaryAmountFormat germanFormat = MonetaryFormats.getAmountFormat(

System.out.println(germanFormat.format(monetaryAmount)); // 1.202,12 USD

Formatting money according to different countries

More about JSR 354

已有 1 人翻译此段

5. Improve Contended Locking

Lock contention is a performance bottleneck for many multithreaded Java applications. The enhancement proposal looks into improving the performance of Java object monitors as measured by different benchmarks. One of the these tests is Volano. It simulates a chat server with huge thread counts and client connections, many of them trying to access the same resources and simulate a heavy duty real world application.

These kind of stress tests push JVMs to the limit and try to determine the maximum throughput they can achieve, usually in terms of messages per second. The ambitious success metric for this JEP is a significant improvement over 22 different benchmarks. If the effort will succeed, these performance improvements will be rolling out in Java 9.

More about JEP 143

已有 1 人翻译此段

6. Segmented Code Cache

Another performance improvement for Java 9 is coming from the JIT compiler angle. When certain areas of code are executed rapidly, the VM compiles them to native code and stores them in the code cache. This update looks into segmenting the code cache to different areas of compiled code in order to improve the compiler’s performance.

Instead of a single area, the code cache will be segmented into 3 by the code’s lifetime in the cache:
- Code that will stay in the cache forever (JVM internal / non-method code)
- Short lifetime (Profiled code, specific to a certain set of conditions)
- Potentially long lifetime (Non-profiled code)
The segmentation would allow for several performance improvements to happen. For example, the method sweeper would be able to skip non-method code and act faster.

More about JEP 197

已有 1 人翻译此段

7. Smart Java Compilation, Phase Two

The Smart Java Compilation tool, or sjavac, was first worked on around JEP 139 in order to improve JDK build speeds by having the javac compiler run on all cores. With JEP 199, it enters Phase Two, where it will be improved and generalized so that it can be used by default and build other projects than the JDK.

More about JEP 199

已有 1 人翻译此段

What else to expect?

8. HTTP 2 Client

HTTP 2.0 hasn’t been released yet as a standard but it will be submitted for final review soon and it’s expected to be finalized before the release of Java 9. JEP 110 will define and implement a new HTTP client for Java that will replace HttpURLConnection, and also implement HTTP 2.0 and websockets. It wasn’t published as an accepted JEP yet but its targeting Java 9 and we expect it to be included.

The official HTTP 2.0 RFC release date is currently set to February 2015, building on top of Google’s SPDY algorithm. SPDY has already shown great speed improvements over HTTP 1.1 ranging between 11.81% to 47.7% and its implementation already exists in most modern browsers.

More about JEP 110

已有 1 人翻译此段

9. Project Kulla – REPL in Java

Recently announced, a bit unlikely to hit Java 9 but might make it on time with a targeted integration date set in April 2015. Today there’s no “native” Java way to REPL (Read-Eval-Print-Loop). Meaning, if you want to run a few lines of Java to check out them quickly on their own you will have to wrap it all in a separate project or method. There are REPL add-ons to popular IDEs and some other solutions like Java REPL, but no official way to do this so far – Project Kulla might be the answer.

More about Project Kulla

已有 1 人翻译此段
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。




正确的思路应该是使用大版本的工具 小版本的更新 可能会有bug,也就是使用较稳定的大版本。
而不是死守着低版本的东西 怕麻烦 去更新版本 ,怕更新后 项目 出错 又不想浪费时间去 测试 更新后的版本 。又怕更新后的工具版本 有bug 。 前怕狼后怕虎 很多公司都这样吧 可能一些程序员 java 8都不知道 更别提去了解 新特性了


其实java5已经很好用, java6已经够用了, java7又好了不少, java8已经很好了, java9又要好一点了, java确实在不断更好, 为什么不象.net那样一步到位呢?
仍然使用java 5!