Alan Bateman, a member of the Java Platform Group at Oracle said this is in his talk in Java One in September 2016:
No matter what the application is about, there's one set of libraries that every Java program is guaranteed to use without a doubt--the Java Platform. For Java developers to be writing modular Java code, it's essential for the core Java platform and the JDK library to be modular as well. Before Java 9, all the classes and types in the JDK had such complicated inter-dependencies that they resembled a big bowl of spaghetti.
Not only is the final rt.jar bundle unnecessarily large, it makes the JDK code base itself harder to change and evolve. Considering how any type in such a huge code base could be used by any of the other thousands of types in the platform, I wouldn't want to go in there and make any major changes to that code. Another problem with the platform is that it has always lacked ways to hide and encapsulate internal platform APIs such as sun.misc.Unsafe. The platform itself could very well use the same strong encapsulation and reliable configuration benefits that JPMS gives us.
With Java 9, we've finally got a modular JDK to build on top of. Various different sets of related JDK classes are bundled into separate modules, each with its own imports and exports. For example, SQL related types are in a module called java.sql. XML functionality has gone into the java.xml module, and so on. We'll be looking at these out-of-the-box modules in more detail in Chapter 3, Handling Inter-Module Dependencies.
The following is an illustration of a subset of the new Java 9 platform modules. Don't worry about the individual names. We'll cover platform modules in detail in Chapter 4, Introducing the Modular JDK:
Project Jigsaw claims the following as its primary goals. It's important to keep this in mind as you learn about the impact of the modularization of the platform:
- Scalable platform: Moving away from a monolithic runtime and enabling the ability to scale the platform down to smaller computing devices.
- Security and maintainability: Better organization of the platform code to make it more maintainable. Hiding internal APIs and better modular interfaces to improve platform security.
- Improved application performance: Smaller platform with only the necessary runtimes, resulting in faster performance.
- Easier developer experience: The combination of the module system and the modular platform to make it easier for developers to create applications and libraries.
What does this mean for application developers? The most immediate difference is that not all types in the JDK are now accessible in your code. The same mechanisms we saw apply to our modules work with the Java modules too. Any time you depend on a platform class, you'll have to import into your module the right platform module that contains that class. And, even then, you'll be able to use the class only if it has been exported from the module and is public.
This way, the JDK code base also gets all the advantages of the strong encapsulation and reliable configuration that the JPMS promises. There are potential backward compatibility issues though. What if you used a JDK class in JDK 8 or earlier that's now an encapsulated class in a module? That code wouldn't work in Java 9! The platform uses the encapsulation features to protect certain internal JDK classes from external use. So, any code that depends on such classes in Java 8 or earlier cannot be migrated to Java 9 without removing that dependency first. There are a few challenges associated with moving code from Java 8 or earlier to Java 9. We'll look at Java 9 migration-related challenges and best practices in Chapter 9, Module Design Patterns and Strategies.
Another important aspect of modularity that most modular platforms have to deal with, and we haven't covered so far, is versioning. Are modules versionable? Can you declare dependencies between modules that specify which versions of the modules need to work together? You cannot! Java Platform Module System does not support versioning today. We'll briefly examine the reasons why in Chapter 3, Handling Inter-Module Dependencies.
