Java 9 Telescope

This post will be updated with new features targeted at the upcoming Java 9 release (last updated: 20/11/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 the JEPs (JDK Enhancement Proposals) that target the release keep getting 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. [ExpectedREPL in Java

Update 20/11/2014:

10. [Accepted] Unified JVM Logging
11. [Accepted] Compiler Control
12. [Accepted] Datagram Transport Layer Security (DTLS)
13. [Accepted] HTML5 Javadoc

Additional fixes / cleanup:

14. [Accepted] Elide Deprecation Warnings on Import Statements
15. [Accepted] Resolve Lint and Doclint Warnings
16. [Accepted] Milling Project Coin
17. [Accepted] Remove GC Combinations Deprecated in JDK 8
18. [Accepted] Process Import Statements Correctly

19. 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.

More about JEP 201

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.

More about JEP 102

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

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

More about JSR 354

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

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

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

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

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

Update (20/11/2014):

10. Unified JVM Logging

Today it’s hard to make sense of the root cause for performance issues and crashes of the JVM. One way to tackle this is introducing one single system for all JVM components that would allow fine-grained, and easy-to-configure JVM logging. Currently, different components of the JVM use different mechanisms and conventions for logging, making it harder to debug.

More about JEP 158

11. Compiler Control

Taking on the HotSpot JVM and extending the controls for compiler options down to the method level. After this update, the JIT compiler options could be modified even during runtime depending on the specific method that’s being compiled.

More about JEP 165

12. Datagram Transport Layer Security (DTLS)

Adding DTLS support, a secure way to communicate using datagram protocols such as UDP.

More about JEP 219

13. HTML5 Javadoc

Bringing Javadoc up to speed with the HTML standard: Generating modern HTML5 documentation.

More about JEP 224

Fixes / Cleanup:

14. Elide Deprecation Warnings on Import Statements

More about JEP 211

15. Resolve Lint and Doclint Warnings

More about JEP 212

16. Milling Project Coin

More about JEP 213

17. Remove GC Combinations Deprecated in JDK 8

More about JEP 214

18. Process Import Statements Correctly 

More about JEP 216

 

19. 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.

 

Takipi shows you when and why your code breaks in production. It detects caught and uncaught exceptions, HTTP and log errors, and gives you the code and variable state when they happened. Get actionable information, solve complex bugs in minutes. Installs in 5-min. Built for production.

 

Further reading:

threadfred

Thread Magic Tricks: 5 Things You Never Knew You Can Do with Java Threads

Java 8

Java 8 Exceptions have never been so beautiful 

Some kind of monster @ OverOps, GDG Haifa lead.
  • Chuck Remes

    No coroutines or fibers? Bah.

    • Christopher Probst

      They do not solve anything. They make the whole system much more complex without real benefit. If you want synchronous IO use a language like Go where this is baked in from the very beginning. First you want fibers, than channels, than a select statement. Just forget it. I really like Go, but its concept do not fit well to Java, its just another language with other patterns.

  • darkcg

    What about project Sumatra and GPU acceleration? Still postponed?

  • Pingback: 21 Nov, 2014 | My Link Log()

  • i2matrix

    why do they shy away from implementing getter – setter /properties , even after so much user demand. Being able to use obj1.x =12, instead of obj1.setX(12) is so much of a relief. This is available in C#,Scala,Groovy,Python,Ruby,…Every language worth its sault. What is the propblm in implementing getter-setter/properties in java??

    • mr_z0123

      I get the feeling the folks in charge of language features do what they want and give lip service to the rest.

      Just switch over to groovy or the other languages you noted.
      Life is just too short to deal with bureaucracy.
      I did that about 3 years ago and now have a pleasant demeanor. 🙂

      But for what its worth, I agree with you.

  • Herman Bovens

    I would have liked optional arguments.

    • i2matrix

      🙂 “upgrade” to scala.
      But If you want java like syntax only, then “Statically Typed” Groovy is also good, with not much performance difference now .

  • mr_z0123

    operator overload?

    Why do we still have to live with:
    Money total = amt1.add(amt2);
    instead of:
    Money total = amt1 + amt2;

    • i2matrix

      “upgrade” to scala.
      But If you want java like syntax only, then “Statically Typed” Groovy is also good, with not much performance difference now

      • mr_z0123

        I am a big groovy fan.
        Pretty much given up on java.
        Only use it when its dictated to do so.

    • Aurelien Boubennec (AurelienB)

      or Xtend!

  • i2matrix

    In java 9, they should also inbuilt implement JEP 191 (FFI inspired from JNA). for details see:
    http://openjdk.java.net/jeps/191
    it can be used for easily implementing native-backed features like NIO, advanced file system metadata, and process management. Using the FFI API will be the preferred way to bind native code and memory, instead of JNI.

  • hb3333

    1) It will be great if Java has multi-line interpolated strings. It is
    pain in the ass now to create long string. This should be relatively
    simple addition.
    2) real attributes