The goal of Project Jigsaw is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. It was postponed many times, it’s planed now for java 9 and until now no announcement from oracle that it’s postponed again.
Here’s what Mark Reinhold said about the motivations behind the Jigsaw modular system:
A standard module system for the Java Platform will ease the construction, maintenance, and distribution of large applications, at last allowing developers to escape the “JAR hell” of the brittle and error-prone class-path mechanism.
It sounds very good, but It Isn’t the same motivations as the mature OSGi? especially since they are many known java applications using it like Eclipse and JDeveloper. Why waiting for many years to provides another module system?
A first possible explanation , is that the JRE itself needs to be modular. and in this case a modular system must be managed by the JRE, and not by an external container like OSGi.
Jigsaw has two major benefits :
- Modularise the JRE itself.
- Offer a module system that may be used by other Java libraries and applications.
1 – Modularise the JRE itself
The standard Java 8 is structured with jars like all previous Java versions. Each jar contains many types, and almost all types are present in the rt.jar,
The current JRE structure has two major drawbacks:
- The JRE is monolithic which has many incovenients as Mark Reinhold describe in this post.
- Some dependency cycles exist between jars, and many dependency cycles exist between packages as shown in the following DSM. The black cells represents a dependency cycle.
The JRE implementing Jigsaw is structured by using modules, and each major features are isolated to a specific module, the structure became cleaner as shown by the following dependency graph.
2- Provides a system to modularise java applications
A module is a collection of Java types with a name, an optional version number, and a formal description of its relationships to other modules. In addition to Java types a module can include resource files, configuration files, native libraries, and native commands. A module can be cryptographically signed so that its authenticity can be validated.
The Java programming language is extended to include module declarations for the purpose of defining modules, their content, and their relationships to other modules. A compilation unit containing a module declaration is, by convention, stored in a file named module-info.java and compiled into a file named module-info.class.
And to understand better the module concept, let’s go inside the jndi module from the JRE, and explore its declaration.
module jdk.jndi @ 8-ea {
requires local jdk.auth.internal@8-ea;
requires local jdk.base.internal@8-ea;
requires optional jdk.desktop@8-ea;
requires jdk.rmi@8-ea;
requires jdk.tls.internal@8-ea;
requires optional service javax.naming.ldap.StartTlsResponse;
provides service sun.net.spi.nameservice.NameServiceDescriptor with sun.net.spi.nameservice.dns.DNSNameServiceDescriptor;
// default view exports
exports com.sun.security.auth.*;
exports com.sun.security.auth.module.*;
exports javax.naming.*;
exports javax.naming.directory.*;
exports javax.naming.event.*;
exports javax.naming.ldap.*;
exports javax.naming.spi.*;
view jdk.jndi.internal {
exports com.sun.jndi.toolkit.url.*;
exports sun.net.dns.*;
permits jdk.cosnaming;
permits jdk.kerberos;
}
}
Let’s discover each module section
requires
Jndi depends upon other modules, until now nothing new, the jars also depends on other ones, but what’s new is that with Jigsaw approach we specify all the modules required with their versions, and the version specified is the used one, we can also specify a range of versions.
It’s true that Maven provides also an interesting way to specify dependencies between jars, but with Jigsaw we have more control and flexibility when defining module dependencies.
The following dependency graph show that jndi uses only modules specified by its requires section.
provides
A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself.
A module can declare that it provides a service and specify the service provider by using the “with” keyword.
For example for jndi we have this line in its module declaration:
provides service sun.net.spi.nameservice.NameServiceDescriptor with sun.net.spi.nameservice.dns.DNSNameServiceDescriptor;
What specify that it provides the service sun.net.spi.nameservice.NameServiceDescriptor and the implementation is sun.net.spi.nameservice.dns.DNSNameServiceDescriptor.
exports
An exports clause in a module declaration makes the public types in the package it names available to other modules, so we can with Jigsaw defines boundaries, and not all public types could be used from other modules, we must explicitly specify which types are visible.
The jndi module exports many packages, what means that only these exported types could be used from other modules.
view
In large software systems it is often useful to define multiple views of the same module. One view can be declared for general use by any other module, while another provides access to internal interfaces intended only for use by a select set of closely-related modules.
For example with jndi we want that com.sun.jndi.toolkit.url be visible only for cosnaming and kerberos modules, as specified in the module declaration.
view jdk.jndi.internal {
exports com.sun.jndi.toolkit.url.*;
exports sun.net.dns.*;
permits jdk.cosnaming;
permits jdk.kerberos;
}
This way we have more flexibility to define module boundaries.
Create your first modular application
The better way to understand the Jigsaw modularity system is to create a mini modular application and explore the module possibilities. For that you can get the JDK9 early acces and Follow the steps from this quick start web page.
Conclusion
The current JRE has many problems, it’s monolithic and contains many dependency cycles, and since 2006 some java experts talk about the necessity to modularise the JRE itself, which will be The first major benefit of Jigsaw. However uses it to modularise the java libraries and applications is certainly not going to be easy to achieve. Indeed the OSGi is already adopted by many applications, it exist since 2000 it’s mature and provides many interesting modularity features. And refactoring the existing application is not an easy task.
But if the known IDEs provides out of the box some wizards to create easily modular applications, it could encourage the new application developers to use the Jigsaw modularity system.