Benefits of JPMS/Project Jigsaw for Small Applications / Libraries

Question

I understand the benefits of the Java Platform Module System (JPMS) for large applications, but is there any reason to make a small library or application into a (single) module? If so, are Modular Jar Files the best means of accomplishing this, or is the normal approach preferred?

Going forward, will there be performance implications for modularized v. classpath programs?

Answer 1

Immediate performance implications include the following:

• Modularized applications can opt to use jlink so that the distributable runtime is reduced in size: it only uses the modules you require. So if you don't need Swing, Corba, etc, it does not reside on disk. (more info here).
• Modularized applications use the module graph for classloading; the algorithm for this is much faster than the linear search of classpath (more info here).

This is by no means a guarantee that your app will be faster, but the above is undeniably attractive.

Longer term, consider this:

• Though experimental in JDK 9, there is an AOT compiler that (for Linux x64) will compile the java.base module to native code. This is likely the path forward for future Java releases. Surely this will improve startup time in the future. (again, more info here)

Answer 2

If so, are Modular Jar Files the best means of accomplishing this, or is the normal approach preferred?

I'm not sure what you you mean by "the normal approach" - modular JARs are the "normal approach" to create artifacts that the module system will create a module for.

[I]s there any reason to make a small library or application into a (single) module?

Yes, a few:

• Developers creating a modular application or using a modular library benefit from reliable configuration, where they can only launch their application if all dependencies are present - this is a benefit no matter how large the application/library is.

• As a library designer you can hide internals. While strong encapsulation is only effective if your modular JAR is put onto the module path, the module descriptor still documents your intent in code, and allows you to more unscrupulously change your code. Application developers benefit as well because they can no longer accidentally depend on unsupported implementation details.

• Even in small applications and libraries, services might be used to decouple different aspects of functionality and make code more easily extensible.

• Only "real" modules (as opposed to automatic modules) can be included in a runtime image by jlink. Not providing a modular JAR robs your users of a library of that possibility.

Also note that you never know which small application or library might turn into something bigger. :)

Going forward, will there be performance implications for modularized v. classpath programs?

While building the module graph and verifying modules costs time, the module system should make it up with an improved class loading strategy: It records for every package which module exports it and loads types from that package directly from that module instead of having to scan the entire class path. either way, I don't think this should be a deciding factor.