For the argument, let it be argued that Java 8 (and earlier) already has the “shape” of modules (jars) and a modular system (class path). But problems are well known with them.
By exploring problems, we can illustrate the motivation of Jigsaw. (It is assumed that we do not use OSGi, JBoss Modules, etc., which certainly offer solutions.)
Problem 1: the public is too public
Consider the following classes (suppose both are publicly available):
com.acme.foo.db.api.UserDao com.acme.foo.db.impl.UserDaoImpl
At Foo.com, we can decide that our team should use UserDao and not use UserDaoImpl directly. However, there is no way to enforce this path in the classpath.
In Jigsaw, a module contains the module-info.java file, which allows us to explicitly indicate what is publicly available for other modules. That is, the public has a nuance. For example:
// com.acme.foo.db.api.UserDao is accessible, but // com.acme.foo.db.impl.UserDaoImpl is not module com.acme.foo.db { exports com.acme.foo.db.api; }
Problem 2: unbridled reflection
Given the classes in # 1, someone can still do this in Java 8:
Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl"); Object obj = c.getConstructor().newInstance();
That is: the reflection is powerful and significant, but if it is not checked, it can be used for unwanted penetration into the internal parts of the module. Mark Reinhold has a rather disturbing example . (SO post here .)
In Jigsaw, strong encapsulation makes it possible to deny access to the class, including reflection. (This may depend on the command line settings in anticipation of a revised technology specification for JDK 9.) Note that since Jigsaw is used for the JDK itself, Oracle claims that this will allow the Java team to quickly implement the internal platform environment.
Problem 3: the class path erases architectural relationships
The team usually has a mental model about the relationship between the jars. For example, foo-app.jar can use foo-services.jar , which uses foo-db.jar . We can argue that classes in foo-app.jar should not bypass the "service level" and use foo-db.jar directly. However, there is no way to provide this via the classpath. Mark Reinhold mentions here .
In comparison, Jigsaw offers a clear and reliable accessibility model for modules.
Problem 4: monolithic runtime
Java runtime is in monolithic rt.jar . On my machine, it's 60+ MB with 20k classes! In the era of microposts, IoT devices, etc. It is undesirable to have Corba, Swing, XML files and other libraries on disk if they are not used.
Jigsaw breaks JDK itself into many modules; for example java.sql contains familiar SQL classes. There are several advantages to this, but the new jlink tool. Assuming the application is fully modular, jlink creates a distributed image at runtime that is cropped to contain only the specified modules (and their dependencies). Looking ahead, Oracle foresees a future where JDK modules are compiled on time into native code. Although jlink is optional, and AOT compilation is experimental, they are key indicators of where Oracle is heading.
Problem 5: version
It is well known that the path to classes does not allow the use of several versions of the same bank: for example. bar-lib-1.1.jar and bar-lib-2.2.jar .
Jigsaw does not solve this problem; Mark Reinhold argues the rationale here . The bottom line is that Maven, Gradle, and other tools are a great ecosystem for dependency management, and another solution would be more harmful than profitable.
It should be noted that other solutions (e.g. OSGi) do address this issue (and others other than # 4).
Bottom row
These are some key issues for Jigsaw that are caused by specific problems.
Please note that explanation of disputes between Jigsaw, OSGi, JBoss Modules, etc. is a separate discussion owned by another Stack Exchange site. There are much more differences between the solutions than described here. Moreover, sufficient consensus was reached on the approval of the public review revision bulletin for JSR 376.