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
- [Accepted] Project Jigsaw – Modular Source Code
- [Accepted] Process API Updates
- [Accepted] Light Weight JSON API
- [Accepted] Money and Currency API
- [Accepted] Improved Contended Locking
- [Accepted] Segmented Code Cache
- [Accepted] Smart Java Compilation – Phase Two
- [Expected] HTTP 2 Client
- [Expected] REPL in Java
- Where do new features come from?
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.
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];
in.read(outputBytes);
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.
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!
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( Locale.GERMANY); System.out.println(germanFormat.format(monetaryAmount)); // 1.202,12 USD
Formatting money according to different countries
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.
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.
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.
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.
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.
Bonus: Where do new features come from?
JEPs and JSRs don’t usually pop out of nowhere, here’s the structure that holds it all together:
- Groups – Individuals and organisations with a mutual interest around a broad subject or a specific body of code. Some examples are Security, Networking, Swing, and HotSpot.
- Projects – Efforts to produce a body of code, documentation or other effort. Must be sponsored by at least one group. Recent examples are Project Lambda, Project Jigsaw, and Project Sumatra.
- JDK Enhancement Proposal (JEP) – Allows promoting a new specification informally before or in parallel to the JCP, when further exploration is needed. Accepted JEPs become a part of the JDK roadmap and assigned a version number.
- Java Specification Request (JSR) – The actual specification of the feature happens in this stage, can be either coming through Groups/Projects, JEPs or from individual JCP (Java Community Process) members. An umbrella JSR is usually opened for each Java version, this has yet to happen with Java 9. Individual members of the community can also propose new Java specification requests.
| Reference: | Java 9 – The Ultimate Feature List from our JCG partner Alex Zhitnitsky at the Takipi blog. |
My personal wishlist:
1. pattern matching (like in scala)
2. automatic property accessors (like in c#)
3. dynamic method missing handlers (like ruby and groovy)