-
Java 9
|
October 26, 2017
Prepare for JDK 9
Java 9 introduces a modular system which is moving away from today’s monolithic Java SE platform. Backward compatibility is one of the main priorities and the Oracle engineering team has worked on a smooth transition to Java 9. Nonetheless, there are a number of key changes that you need to understand. Armed with the information from Alan Bateman’s presentation “Prepare for JDK 9,” and additional pointers in this blog you will avoid a lot of frustration.
Chapters
Other smaller changes in JDK 9 - 23:59
There is a new runtime version API, which can help you avoid parsing the Java version string. (24:11)
New binary structure for JRE and JDK - JEP 220 (26:35)
Class loader minor changes (29:28)
Multi-release JAR files - JEP 238 (32:48)
Compile for older platform versions - JEP 247 (37:09)
jdeprscan, a tool to scan classes for deprecated APIs (38:26)
Summary of steps to prepare for JDK 9 (39:04)
6 Steps to Prepare for JDK 9
- Upgrade tools and libraries to the newest versions that support JDK 9
- Decide how you can migrate your Java EE functionalities in the JDK
- Run jdeps to check whether your or third party code use any internal APIs
- Look for “illegal reflective access” warnings, submit bugs
- Audit code that parses the version string
- Read the release notes
In JDK 9, you can use the class path and class loading the same way you did in JDK 8. This means that you do not need to rewrite your code to move to JDK 9. You don’t have to migrate to modules to move to JDK 9. Class path and modules can coexist and will allow you to migrate your code to modules over time. The sun.misc.Unsafe is still part of JDK 9 and works the same way as in previous releases. Update to the latest update of Java IDEs (NetBeans, Eclipse, IntelliJ…) and Maven, all of which have support for JDK 9.
Six Java EE libraries in JDK are no longer shared by default in JDK 9. Those Java EE deprecated APIs are java.corba, java.transaction, java.activation, java.xml.bind, java.xml.ws, java.xml.ws.annotation. They have been deprecated in JDK 9 and will be removed in a future release. They are disabled by default in JDK 9. Their packages will not compile in Java 9 and give an error message. The documentation gives you migration options to enable those libraries in JDK 9. This should be a temporary solution because they are scheduled to be removed in a future release.
Most internal APIs will be inaccessible by default, but some critical, widely-used internal ones will remain accessible until supported replacements exist. JEP 260, about encapsulating most internal APIs, describes which critical internal APIs will remain accessible.
You may not be aware that your applications are using JDK-internal APIs because you may depend on a third party library that uses such APIs, for example. Use Jdeps, Java dependency analysis tool, to identify those APIs. The tool also proposes suggestions for replacements when available. Check out the Jdeps main page.
When you compile code with direct reference to internal APIs, the compilation fails. At runtime, the goal will be to encapsulate all the internal APIs in the future. There is a command line option —-illegal that allows you to debug further or deny illegal access to test future behavior. This will help you get ready for future Java releases showing you the impact of removed APIs.
Additional links to bookmark:
JEP 277: Enhanced Deprecation
JEP 260: Encapsulate Most Internal APIs
JDeps tool
Related Blogs:
Prepare for JDK 9
Looking at JDK 9 with Categories