Assuming Oracle keeps its ducks in order, work is ticking away nicely on next year’s Java 9 release, provisionally due on September 22nd. As of this morning, there’s a whole new early access build (JDK 9 b66) ready to get your teeth into.
Given that Java 9 will be introducing a few potentially breaking changes around its tooling and internal APIs, it’s a good idea to get to know and prepare for the adjustments you’ll be needing to make before it officially goes GA. The bulk of these issues will centre on code that relies on “deprecated, removed, unsupported, internal or unspecified functionality.”
Whilst Compact Profiles in Java 8 brought what Mark Reinhold has dubbed a “poor man’s” version of modularity, as you’re probably aware, Java 9 will be going full throttle with modularisation of the platform.
Along with the obvious benefits of breaking down monolithic systems, modularity will bring improvements to performance and security. As the JDK has grown and evolved into the hulking beast it is today, various interconnections have grown up around it that have slowed it down.
Oracle are also looking to spring clean com.sun.* APIs from the platform which, at this point, don’t really have a function beyond helping external libraries operate [For a full explanation on the API issue by Java arch-mage Mark Reinhold, jump ahead to 05:58 on the linked Parleys presentation: ‘Java 9 – Make Way for Modules‘]. By making these inaccessible, not only will it strengthen Java’s security, it’ll also help make the platform easier to maintain.
These are the current potential snags as listed on the official Wiki Outreach page. Bear in mind that more could be added as Java 9 continues to evolve or more issues come to light:
- Unified JVM Logging: Set to introduce a common logging system for all components of the JVM, this JEP could potentially alter log message formats and the meaning of some JVM options.
- Removal of GC Combinations Deprecated in JDK 8: Targeted to sweep away GC combinations which were deprecated in Java 8, anyone who uses code that relies on the now deprecated links will need to update their JVM-startup command lines.
- Modular Run-Time Images: Part of the big push for modularity, this JEP, which effectively landscapes the the JDK and JRE run-time images to accommodate modules, could be an issue for code that depends on; “the removed endorsed-standards override mechanism, the removed extension mechanism, and the existence of rt.jar and tools.jar files as well as the old directory layout of files in the JDK & JRE installation image.”
- New Version-String Scheme: A simplification of Java’s version-string scheme, this JEP is intended to make it easier to distinguish major, minor, and security-update releases. Any code which relies on the old version string scheme will need to be updated once this is live.
- Removal of Launch-Time JRE Version Selection: This JEP will be taking away the ability to request a version of the JRE that is not being launched at JRE launch time. Code that hinges on this faculty will need to be reviewed.
- Removal of the JVM TI hprof Agent: Now that the hprof agent has been superseded by better alternatives, it’s time to send it on its way. Code that works with the hprof agent library could be affected.
- Removal of the jhat Tool: Ye olde jhat tool is also disappearing, and could potentially leave some code problems in its wake.
- Milling Project Coin: Rather than a Project Coin 2.0, this initiative is an effort to refine the “rough edges” it introduced. If your code uses the underscore (“_”) as an identifier, it could be a problem once you jump to JDK 9, where it will be regarded as an error.
Away from future issues, the more immediately useful early access build for JDK 8u60 b18 is also now available for exploration and bug hunting. You can click here for a fulsome list of changes. As usual, both of these Java Early Access builds are available on java.net.