BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Long Awaited Java 9.0 Releasing This Week

| by Amit K Gupta Follow 3 Followers on Sep 18, 2017. Estimated reading time: 5 minutes |

The long awaited next release of Java SE, version 9, is being released on September 21, 2017 and with it come some major changes.

The key change in JDK 9 is the introduction of "a new kind of Java programming component, the module, which is a named, self-describing collection of code and data", according to Oracle. The key aim of the modules technology is to reduce the size and complexity of both Java applications and the core Java runtime itself. To this end, the JDK itself has been modularized, an approach that Oracle intends to improve performance, security and maintainability.

To support Java 9 modules, a new modular JAR file with a module-info.class file in its root directory has also been introduced. Oracle has also introduced tooling to allow a set of modules to be assembled and optimized into a custom runtime image, without requiring a full Java runtime to be present. Other changes as a consequence of modularisation include the removal of rt.jar and tools.jar from the Java runtime image.

InfoQ spoke to Ben Evans, a member of the Java Community Process (JCP) Executive Committee, about his thoughts on the module system in Java 9.0

Evans: I think the applications that are in the most dire need of refactoring may be the best targets for modularisation. If you're already in Lava Flow / God Class / Stovepipe System hell and your stakeholders know it, then it may be easier to persuade them to do a full drains up refactor and that the incremental effort to go to a fully modular solution (vs just refactoring and moving to Java 8) is worth it.

Since Oracle has announced that Java 8 will be a long-term support release, supported through 2022, Evans thinks that a lot of applications might stay on Java 8 and not upgrade to Java 9 at all. Evans added that some applications may decide to leave the dev and build toolchain on version 8 and use a Java 9 runtime in production.

This could make a lot of sense for certain applications. For example, I've seen ecommerce sites with large heaps that contain ~40G of string data. Java 9's Compact Strings would cut that memory usage in half. That would, in turn, have a positive impact on GC performance. For some applications (including perhaps large Solr installations or similar), that single benefit may itself be worth upgrading to 9 at runtime.

Java 9 makes G1 the default garbage collector replacing Parallel GC, which was previously the default. Evans commented on this change:

This change can be significant, because G1 does more work on the application thread than Parallel (which does basically none, and relies on the GC threads to do virtually all of the work to manage memory). This means that switching to G1 will introduce extra work on the app threads and impact performance of the application directly.

In many cases (perhaps even most) this additional performance overhead is not an issue. However, in the field, I have observed that a significant percentage of workloads do see an observable decrease in performance when moving from Parallel to G1. For some of these applications, this performance degradation is unacceptable, and so they are unable to move to the G1 collector. With G1 becoming default, this now potentially affects every application moving to Java 9.

InfoQ asked Martijn Verburg, CEO of JClarity and co-organizer of London Java User Group, if it is advisable for large code bases to refactor into modules.

Verburg: Yes and hopefully the large code base that you are dealing with has already been split into some semblance of a modular structure whether that be via OSGi, Maven modules, JBoss Modules or just a set of home grown rules about a clear package and interface structure.

Verburg has some good common modularisation advice and also points out things developers should watch out for when adopting Java 9’s module system:

  • Read Paul and Sander's book on Java 9 modularity- it's the definitive guide, which covers all of the gotchas and how the relationship between modules, packages and JARs work.
  • Have well defined interfaces at the boundaries of your modules and code to those interfaces.
  • Don't have split packages, that is, your packages must not be split across two modules.  The Adopt OpenJDK programme's Patrick Reinhart has a detection tool that you can run on your existing code.
  • Make sure you don't have cyclical dependencies (Jigsaw won't allow them).
  • The way modules are laid out in source will look differently than what you're used to; make sure that your build tools can cope accordingly.
  • Jigsaw does not support versions.

According to Verburg, the key things are to fix up cyclical dependencies, split packages and make sure to code to interfaces. This should be done to existing code base before attempting modularisation with Jigsaw. He also addressed the myth that only modularised applications can run on Java 9.

There's been a bit of FUD going around where people have mistakenly said that you need to have a modularised app in order to run on Java 9.  This is simply not true and you can run your existing classpath based applications on Java 9 just fine.  There are a few new security restrictions, which means you may need to set a few special runtime flags (until you refactor your code to use the new safer way of accessing Java internals etc.), but even there the default is to warn you, as opposed to stopping you (Java 10 will enforce that further).

Verburg thinks Jigsaw is the foundation that will allow Java to move faster, and credits Mark Reinhold, Alan Bateman, Mandy Chung and the rest of the Jigsaw team who worked tirelessly for many years to make that happen.

Java 9 also introduces the jshell tool. This command line environment brings a form of Read-Eval-Print-Loop (REPL) to the Java platform. This is intended to facilitate prototyping and exploration of coding options with immediate results and feedback.

Both Verburg and Evans are excited to see the inclusion of jShell in Java 9, although they also mention disappointment that HTTP/2 is shipped as an incubator module in Java 9. Given considerable community interest in this feature and offers of help, Evans thinks Oracle should have committed sufficient engineering resource to ship HTTP/2 as GA.

A complete list of changes coming in JDK 9 can be found on Oracle’s website. With the announced switch to a six-month release cycle, the release of Java 9 represents the last of the releases driven by "keystone" features that have characterized Oracle's stewardship of Java to date. The next phase of Java's evolution seems set to be driven by shorter, feature-oriented releases. It remains to be seen whether this will allow Java to retain its position among leading serverside technologies.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

good by xw kong

good news!

The revolution by Sheikh Sajid

The revolution is finally being delivered

Oracle has said Java 8 until Sept 2018 ? by tony rutherford

Oracle has released that Java 8 is only going to be supported to Sept 2018 public release which conflicts with the news that this article is stating.
"Since Oracle has announced that Java 8 will be a long-term support release, supported through 2022"

Can you give us your views on this announcement from Oracle regarding Sept 2018 as opposed to 2022 please ?

Re: Oracle has said Java 8 until Sept 2018 ? by Ben Evans

A minor clarification - Oracle Java 8 will be supported by Oracle as a supported release until 2025. However, that is via purchase of an Oracle support contract.

My understanding from an official Oracle spokesperson was that free public support was also extended from 2018 to 2022, but I will check with them & ensure that I understood correctly.

In practice, I would expect a much longer supported release time, as Oracle Java 8 binaries are basically interchangeable with OpenJDK 8 (apart from some minor edge cases for desktop applications) so users of Oracle JDK 8 always have a migration path to OpenJDK.

Re: Oracle has said Java 8 until Sept 2018 ? by tony rutherford

thanks for the swift reply Ben. I looked at the following URL this morning and then asked the question. www.oracle.com/technetwork/java/eol-135779.html
if you can speak to your colleague about the Sep 2018 Oracle announcement and the counter date from your article that would be appreciated.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT