Are you worried about making the switch to the Java 9 platform? Here are 10 misconceptions that have been officially debunked
Mark Reinhold, Chief Architect for the Java Platform Group, participated at a Devoxx conference this year and had the chance to share his thoughts on Jigsaw and Java 9 during a session called #askarch. During the session, members of the audience asked Reinhold various questions about the SE platform and JDK in an open Q&A session. A main theme was the most common misconceptions about Jigsaw and Java 9.
On a related note, we’ll be holding a webinar to share our own thoughts on Java 9, a week after its release. Join us to hear about our first impressions of the new platform and how we are expecting it to revolutionize the way we build large-scale applications.
Now, let’s take a look at what Reinhold has to say.
— OverOps (@overopshq) September 14, 2017
1. Maven doesn’t work on Java 9
Yes, it does. For those who are still skeptical, the Chairman of Apache Maven, Robert Scholte, announced via Twitter that all Maven versions 3.0 and later run on Java 9. There might still be some issues with some plugins, but for the most part everything is working as expected and Scholte is confident that everything will be working by the General Release date.
Yes indeed, every Maven 3.0+ runs fine on Java 9. This should not be a concern. Only a few plugins which need to be fixed. https://t.co/Fcd6ZlrU5I
— Robert Scholte (@rfscholte) May 16, 2017
2. The tools, libraries, and frameworks that I count on, don’t work on Java 9
There is a long list of tools and frameworks that work with Java 9. To name a few:
The developer team at Oracle reached out to the maintainers of these tools and frameworks to ensure that Java users won’t lose compatibility and access.
3. I have to modularize everything before I can use Java 9
Nope. The class path is still there, and it will be for the foreseeable future. If you were to import an application that was built in Java 8, it should still work in Java 9 running on the classpath with few problems. One problem that you will have to face is dealing with any dependencies on internal APIs. Implementing strong encapsulation was one of the main goals for Project Jigsaw, but with it, we’ll lose access to all non-critical internal APIs. A short list of critical APIs will remain accessible in a JDK-specific module as stated in the JDK Enhancement Proposal (JEP 260):
- sun.misc.Unsafe (The functionality of many of the methods in this class is now available via variable handles (JEP 193).)
- sun.reflect.Reflection::getCallerClass(int) (The functionality of this method may be provided in a standard form via JEP 259.)
In response to the fear that strong encapsulation would ruin backwards compatibility in Java 9, and “To help the entire ecosystem migrate to the modular Java platform at a more relaxed pace, [Mark Reinhold proposed] allowing illegal reflective access from code on the classpath by default in JDK 9, and to disallow it in a future release.” Because of his proposal, we will now have access to non-critical APIs “via a command-line flag at both compile time and run time.”
Still, if you find yourself handling dependencies on these APIs, your best option is to find them and replace them with maintained APIs.
4. Module systems like OSGi don’t work on Java 9
Wrong. These module systems will work with the classpath as intended as long as OSGi doesn’t use internal APIs. There are no intentions to block use to these 3rd party module systems.
5. Java 9 is going to fragment the Java community because code on the classpath can’t use the modules
Also wrong. Code on the classpath can read all of the public and protected types of resolved modules. This allows for gradual migration of larger systems. In addition, a library or a framework that is shipped as a .JAR file can be converted to a module.
6. Strong encapsulation is the only roadblock to Java 9 adoption
It’s not the only one! Internal APIs that people have grown to rely on are now hidden. But there’s a lot else going on in this version.
Rt.jar is being replaced by a new, more reliable format. The layout of the system image is different. A bunch of system classes were privileged to improve security meaning they are loaded by a classloader different from the bootstrap class loading. The version string format changed.
All of the changes that come with Java 9 may cause some bumps or roadblocks during the transition period.
7. sun.misc.Unsafe won’t be in Java 9 and everything is going to break
Don’t worry! The sun.misc.Unsafe API and a few other frequently-used internal APIs will still be accessible in Java 9.
One of Jigsaw’s main goals is to implement strong encapsulation in the SE platform. That means, though, that many of the internal APIs that we’ve come to rely on won’t be accessible. While strong encapsulation is certainly not the only roadblock, it will definitely cause some problems. To address public concern about the impact of losing access to certain internal APIs, Reinhold proposed a 3-step process for dealing with these APIs which we outlined in a previous post:
- If it has a supported replacement in JDK 8 then it will be encapsulated JDK 9
- If it does not have a supported replacement in JDK 8 then it will not be encapsulated in JDK 9, so that it remains accessible to outside code; and, further,
- If it has a supported replacement in JDK 9 then it will be deprecated and encapsulated in JDK 9, or possibly even remove it, in JDK 10.
Basically, the plan is to allow illegal access to the most frequently used internal APIs until a replacement standard API is introduced to the platform.
8. Jigsaw is going to fix the “multiple versions” problem
Not yet. While there was hope from some parts of the Java community that Java 9 would, “allow multiple distinct modules of a given name to be loaded in a convenient fashion,” it won’t be coming in this version. Instead, Alan Bateman from Oracle suggests that it should be up to the build tools and containers to solve the problem of dealing with multiple versions of the same module.
9. Jigsaw sucks because it won’t fix the “multiple versions” problem
If it did, then nobody would like it. There are 2 main implications that would come with the solution of the “multiple versions” problem:
- Well-established APIs that work in any way with class loaders would change in incompatible ways. “Any code that makes assumptions about class loader relationships, won’t work like it used to,” says Reinhold.
- The build tools will also need to be enhanced in order to support multiple versions.
Jigsaw is setting us up to fix this issue in the future, but the the ecosystem simply needs to catch up before the team can move forward with it.
10. Modularizing an existing system will be easy!
No. It took 9 years to modularize the JDK. Any large system will take a lot of time and resources to convert to Java 9 from a previous version, and in the end it may not have been worth the trouble. Before modularizing an existing system, weigh the costs against the potential benefits. If it will be worth it, then go for it, but be aware that it might not be. If you’re starting a new project then by all means use modules.
Listen to Mark Reinhold’s talk about these top 10 misconceptions or rewind and watch the full Q&A session right here:
Well, you heard it straight from the source. There are a lot of misconceptions about Java 9 and the module system and these ones have been officially debunked by Mark Reinhold himself.
If you’re still on the fence about making the switch to Java 9 or to the module system or you’re just curious about the new platform, join us for a webinar with OverOps’ VP Engineering Niv Steingarten as he shares his first impressions of Java 9 and how it is expected to revolutionize the way we think of, and build, large scale applications.