Java 9 – Project Jigsaw

26 Jul 2017 Java 9 – Project Jigsaw

So Java 9 is on its way and it’s finally bringing us project Jigsaw. I say finally as this was first meant to be delivered with Java7 and then with Java8. It is now the main new feature for Java 9.

Java Platform Module System

Java Platform Module System, or JPMS, is the catchy name for what is being included from project Jigsaw. It is delivering modularisation of the JDK and anything that you want to put on it.

Why Is It Needed?

There are two main drivers for modularisation:

1. Classpath/Classloader issue
2. Monolithic JDK

Classpath issue

When writing java code you need to understand what dependencies you are using, what Jars are required. Historically this was very painful when lots of dependencies were used. Build tools like Maven go a long way to sorting this out, pulling in all the dependencies of your jar, and all their dependencies and so on.

When these Jars are deployed to the JRE they are all just put into one long classpath. This (ball of mud) is given to the classloader, it then loses all distinction between jars and what their dependencies are, it just sees the classpath as a directory structure for it to scan to find files (classes). This leads to all sort of issues, JAR Hell being a term that covers most of them.

Monolithic JDK

While java has gained many features, the JDK, specifically the RT jar, has become very large to hold them all. In most cases there are a significant number of features that are not used by an application.

This has implications when running on the cloud, running lots of JVMs all having their own rt.jars, or running on small devices that cannot allocate enough memory (consider IoT)

How is it fixed?

With JPMS! JPMS is creating the concept of modules, any jar can be built as a module. It is also breaking the JDK down into modules. Each module declares:

• module name
• export packages (list of packages that can be seen externally)
• import modules (list of modules that are needed to run)

This information is used to create a module path, at compile time and VM initialisation the module path is validated to check that all packages that are used are exported.

This allows a slimmed down JDK giving better startup times and using less memory and makes the VM validate all the required packages are present and visible at startup.

Great – So what’s next?

There are a few issues left with JPMS, a few examples are

• no access to private packages
• automatic module names
• module versioning
• private package name clash

Some of these have been resolved since they were first raised, most private packages in the JDK that are widely used are being made accessible again in the short term.

The issue with automatic module names and no module versioning could end up with a new issue dubbed ‘module hell’. The module model being implemented does not allow versioning so upgrading versions of jar in a complex dependency graph is going to get some of the same issues as Jar Hell had in the first place. This is made worst by automatic module names, consider having two libs/modules both dependent on the same third lib/module. If the third lib/module gets a new name (ie not the automatic name) then both the libs/modules you have included need to be upgrades at the same time.

Alternative Solutions: OSGi/Wildfly

These are two implementations that allow modularisation presently. Will they become redundant with the release of Java9? Or will they work neatly alongside JPMS?

Unfortunately neither is the case. The way these solutions are implemented gives each of their modules it’s own classpath, giving them a much tighter encapsulation and module versioning, allowing multiple versions of a module to be deployed. These issues have been raised with JPMS implementation.

It seems that the people developing JPMS explicitly wanted to make sure that it did not work in the same way as existing modular solutions, with a classloader for each module, meaning there is not complete isolation between the modules.

So OSGi and Wildfly will need to run all apps within them as unnamed modules and then continue with their own modularisation approach.

So everything is now resolved – Right?

Well it’s all started getting political…the JCP to vote ‘No’ to releasing JPMS back in May.

RedHat and IBM both raising significant concerns with the way JPMS has been implemented and the issue this will cause going forward.

RedHat say that this implementation isn’t compatible with real world JavaEE applications, concluding

there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world

Scott Stark – Red Hat’s EC member

IBM say the implementation does not make use of the experience previously gained in other modular systems:

design decisions have been made in the face of experienced module system designers participating in the expert group. The EG are not just there to provide credibility for the process.

Tim Ellison – IBM EC member

Oracle came back with comments that RedHat are trying to

preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem

Mark Reinhold – Oracle’s Java Platform Chief

Similar was implied regarding IBMs use of OSGi . Then go on to warn that voting against the JSR was a

vote against the Java Community Process itself.

Sounds like a veiled threat from Oracle as to the future of the whole Java Community Process. IE if the JCP cannot approve changes going forward then maybe they can dissolve the JCP and make Java into Oracles own language which it can run how ever it likes.

This sounds similar to when Apache resigned it’s place on the JCP after Oracle would not grant a licence for their modular JDK in 2010, stating:

JCP is not an open specification process – that Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses; that the commercial concerns of a single entity, Oracle, will continue to seriously interfere with and bias the transparent governance of the ecosystem

Apache blog

Conclusion

JPMS has now been unanimously approved, with RedHat abstaining. Java 9 is looking like it will be released September 21.

Uptake of JPMS functionality looks like it will be a slow process, especially if you, or your libs, are using any sun internal packages that are not being made public.

Frameworks like OSGi will continue as they are and make use of the slimmed down JDK where possible.

Hopefully by the time there is greater use of JPMS some of the existing flaws will of been resolved, this may allow JavaEE to be integrated with JPMS.