Part III: The Modular JDK and the JDK Historically
Now I would like to turn our attention in this final section to the modular JDK.
20 Years ago the Java platform was small just a few hundred classes and the organization of the JDK was not a problem.
But every year the platform grew bigger and now it's tens of thousands of classes.
The JDK is huge and monolithic. In reality, the Java platform is not one thing, it's more like 25 separate frameworks including the
There is no reason these separate frameworks have to be tightly coupled in one download.
In fact, it is an impediment in developing the JDK. The overly tight coupling (perhaps accidental) raises development and testing costs, which turns into slower platform evolution. In addition, the larger the surface of your platform, the harder it is to secure. It is an impediment to a lot of users, both those who want to run their applications on smaller devices and those who want to run more instances of their application on large systems.
The JDK is huge and monolithic. In reality, the Java platform is not one thing, it's more like 25 separate frameworks including the
- swing UI framework,
- crypto framework,
- scripting framework,
- multiple 4 XML processing frameworks etc.
There is no reason these separate frameworks have to be tightly coupled in one download.
In fact, it is an impediment in developing the JDK. The overly tight coupling (perhaps accidental) raises development and testing costs, which turns into slower platform evolution. In addition, the larger the surface of your platform, the harder it is to secure. It is an impediment to a lot of users, both those who want to run their applications on smaller devices and those who want to run more instances of their application on large systems.
Prior to JDK 9, even if you only wanted a part of the JDK, you had to take all of it. That all changes in JDK 9. We have taken the monolithic JDK and broken it up into a few dozen modules. Some are part of the Java SE specification, some up just parts of the JDK implementation.
Here's a graph of the Java SE modules. At the bottom, there is java.base which everything depends on.
We have broken out the various frameworks into their own modules: 1) instrumentation, 2) logging, 3) XML, 4) scripting, 5) java.desktop which you can require or not require as your needs dictate.
We have broken out the various frameworks into their own modules: 1) instrumentation, 2) logging, 3) XML, 4) scripting, 5) java.desktop which you can require or not require as your needs dictate.
It just has dependencies, so you can say
and be guaranteed to have all of these modules available. Now it's worth mentioning that merely finding these module boundaries and relationships which might be obvious in hindsight was a tremendous engineering effort.
You will find in your own code that
requires java.se
and be guaranteed to have all of these modules available. Now it's worth mentioning that merely finding these module boundaries and relationships which might be obvious in hindsight was a tremendous engineering effort.
You will find in your own code that
- decoupling a monolith is much harder than
- building a loosely coupled system from the beginning.
Migrating to JDK 9
I would like to quickly review the expectations of compatibility from JDK 9. First up there are various technologies from Java EE that ship in the JDK as well as in app servers. Java EE modules are deprecated for removal (use --add-modules)
The list of Java EE modules in JDK 9 includes CORBA, java.xml.bind, jax.xml.ws and common annotations.
java.activation java.corba java.transaction java.xml.bind java.xml.ws java.xml.ws.annotation
These modules are deprecated in JDK 9 and will be removed in a future release.
Because of that they are disabled by default in JDK 9. If you are running code on the classpath, you may need to use the (use )
--add-modulescommand line flag to enable these Java EE modules.
Second, a lot of tools and libraries try to access parts of the JDK that are meant for internal use only. Unfortunately, it will take a while for tool and library developers to move away from this practice.
JDK 9 temporarily allows access to JDK internals, but prints a warning when it happens. Now there's a command line flag to avoid these warnings, so please check with tool and library developers about how to deploy on JDK 9.
What is this exception? What is this warning? What do I have to do? The answer is temporarily use
--add opens.
Migrating to JDK 9
There are also miscellaneous changes in JDK 9 that are unrelated to modules, but might affect code that ran on JDK 8.
Notably code that assumes the Java version string begins with 1 dot or assumes that the JDK lives in a file called rt.jar,
will fail on JDK 9. Again, please check with tool and library developers about which versions are needed to run on JDK 9.
You can't assume that older versions of tools and libraries will run on JDK 9.
Summary of Part III: The Modular JDK
- In the modular JDK it is "Modules all the way down."
- JDK internals are accessible temporarily, in JDK 9.
- You may need to upgrade tools and libraries to their JDK 9 aware versions.
Summary of Summaries
- A module is a set of packages designed for reuse .
- "Automatic modules" assist with migration to modules and
- you may need to upgrade tools and libraries to their JDK 9 aware versions.
There is a huge amount in the module system that I haven't had time to talk about.
- You can encapsulate resources in a module not just classes.
- You can express optional dependencies by programming with services.
- You can build custom system images with the j-link tools (so you can physically drop CORBA right now if you want to)
- You can spin up multiple versions of a library with the module layer API
Book Recommentations
If you are interested in this kind of thing I recommend two books.
1) the first is Java 9 Modularity, which is a pragmatic walkthrough of the entire module system and the modular JDK
Java 9 Modularity
2) The other is Java Application Architecture from 2012. Java Application Architecture
It is a principled look at constructing modular applications amd has nothing to do with JDK 9 or Jigsaw. It has fantastic advice that applies whether or not you use this module system. It is general advice about structuring large Java programs.
2) The other is Java Application Architecture from 2012. Java Application Architecture
It is a principled look at constructing modular applications amd has nothing to do with JDK 9 or Jigsaw. It has fantastic advice that applies whether or not you use this module system. It is general advice about structuring large Java programs.
JDK 9 is available at jdk.java.net/9
If you are a library maintainer, please run jdeps to see what JDK internals you rely on. You can do this even on JDK 8 installs. Everything you ever wanted to know about the module system is discussed in JEP 261 Module System. JEP stands for jdk enhancement proposal.
If you are a library maintainer, please run jdeps to see what JDK internals you rely on. You can do this even on JDK 8 installs. Everything you ever wanted to know about the module system is discussed in JEP 261 Module System. JEP stands for jdk enhancement proposal.
I cannot emphasize enough how much valuable information lives in JEP 261.
In addition, there is JEP 260 which identifies the JDK internal classes that are temporarily exposed in JDK 9 .
JEP 223 which defines the new version strings beginning with 9. JEP 220 discusses how rt.jar has gone away and the structure of the modular jdk.
JEP 200 gives an overview of the Java SE and the jdk modules but if you've read JEP 261, there will not be any surprises.
JEP 223 which defines the new version strings beginning with 9. JEP 220 discusses how rt.jar has gone away and the structure of the modular jdk.
JEP 200 gives an overview of the Java SE and the jdk modules but if you've read JEP 261, there will not be any surprises.
# End of Presentation