Java 9 modules support (JPMS)

[froderick]

Hi,

I have a multi module maven project that makes use of Java modules (module-info.java) to only expose certain packages for other modules to use. The maven support is fairly automatic, maven recognizes that Java modules are in use and supplies those to the jvm when one module depends on another. It also has fallbacks for when a module depends on a jar that doesn’t define a module itself.

My question is, are there any examples of doing this same thing with mill? I found one example related to generating os-specific install packages, but nothing about managing JPMS module interdependencies.

Mill seems like an interesting way to manage a large, modular codebase. Thanks in advance for pointing me in the right direction.

[gamlerhart]

Yes, I think that is something Mill should support at some point. I'm not aware of any current support for it.
I also assume that this might need some work, depending on how the Zinc (the incremental compilation infrastructure library) has support for it or not.

By JPMS support I mostly assume you mean: Instead of assembly a classpath, it assembles a module path and passes things as modules?

[lihaoyi]

I think this sounds reasonable, but I don't have experience with the java module system myself. @froderick maybe you could open an issue with a writeup of what kind of support you would expect, so we on the Mill side can see if we can implement it?

[asarkar]

I came across this question while looking for JPMS support, and have something to add to the discussion. To avoid confusion, I'll use the term "module" to refer to a Java Module, and "mill module" to disambiguate when necessary. I'll use the term "requirements" to refer to a requires keyword in a module-info.java file.

According to this and this example, the module-info.java is placed at the root of the mill module's source file hierarchy. This conflates the main and test module requirements. It seems currently mill either doesn't support JPMS at all, or treats the tests as unnamed modules, because I can build and test successfully without listing the test requirements in the src/module-info.java.

@lihaoyi As for the JPMS support expected, I think what Gradle provides OOTB is pretty good.

Building Modules for the Java Module System

Testing Java Modules

@froderick I don't want to step on your toes, but if you're unable to follow-up on this issue, I'll be happy to open a ticket as requested by @lihaoyi .

[froderick]

Hi Abhijit, Please go ahead, at this rate I’m not going to get to it any time soon. Thanks Michael

…

On Mon, May 5, 2025 at 5:55 AM Abhijit Sarkar ***@***.***> wrote: I came across this question while looking for JPMS support, and have something to add to the discussion. To avoid confusion, I'll use the term "module" to refer to a Java Module, and "mill module" to disambiguate when necessary. I'll use the term "requirements" to refer to a requires keyword in a module-info.java file. According to this <https://github.com/com-lihaoyi/mill/blob/main/example/javalib/publishing/6-jpackage/foo/src/module-info.java> and this <https://mill-build.org/mill/javalib/publishing.html#_java_installers_using_jpackage> example, the module-info.java is placed at the root of the mill module's source file hierarchy. This conflates the main and test module requirements. It seems currently mill either doesn't support JPMS at all, or treats the tests as unnamed modules, because I can build and test successfully without listing the test requirements in the src/module-info.java. @lihaoyi <https://github.com/lihaoyi> As for the JPMS support expected, I think what Gradle provides OOTB is pretty good. Building Modules for the Java Module System <https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_modular> Testing Java Modules <https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular> @froderick <https://github.com/froderick> I don't want to step on your toes, but if you're unable to follow-up on this issue, I'll be happy to open a ticket as requested by @lihaoyi <https://github.com/lihaoyi> . — Reply to this email directly, view it on GitHub <#4368 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE3C3XVLA5F22Q27ALBL3L244YRLAVCNFSM6AAAAABVN5ED7GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBTG4ZDGNI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[asarkar]

#5065

[lefou]

Personally, I don't think the JPMS isn't worth any consideration for applications. There is almost nothing you get except trouble. I worked for many years with OSGi, which is (even today) a proper module system with lots of benefits (besides the complications it brings). I also remember how intensely the Java specification process tried to ignore the existing and stable OGSi spec when writing the JPMS spec, except for it being mostly incompatible.

There is a big "but" though. We probably want to support it anyway when we target Java developers.

But I have a hard to to motivate myself with learning it since there is nothing I get in return for this investment. It would help for the motivation to develop and maintain support, if you could provide some real benefits for users of using JPMS. I mean, expect it being there for itself.

[asarkar]

The benefit is better encapsulation, especially for libraries. For example, I authored a library that provides a JUnit 5 annotation to read test data from a file. I had used the class Preconditions in my implantation when my library wasn’t modular. After converting to module though, my code stopped compiling because Preconditions is only exposed to a limited set of JUnit internal classes, so, I had to remove it and write my own utility.

I think of the benefits of JPMS similar to that of generics. You could argue that because of type erasure, generics is meaningless at runtime, but that won’t stop millions of applications from taking advantage of generics at compile time. Similarly, if a library author wants to enforce tighter encapsulation, they can do so using modules. A non-modular client will not be any wiser, but a modular client will be forced to follow the intent of the author.

[froderick]

In my case, I have several engineering teams that own specific components of a large codebase. Some components depend on the apis of other components. My teams use the Java module system to explicitly define the api boundaries between them. It helps them to carefully manage their interdependencies by isolating implementation details from public contracts.

Compared to osgi, jpms is a lightweight solution for this purpose, especially if there is no requirement for osgi’s isolated classloaders. It works pretty well and wasn’t hard for my teams to learn.

For what it is worth, the jpms provides information a build tool might find useful. For example, if a public class changes in a module with many other modules that depend on it, but that class isn’t exposed outside that module, then there is no reason to recompile all the dependent modules. Depending on how mill is implemented, that information could afford a meaningful performance improvement when building a large modular codebase.

[asarkar]

This Reddit thread is slightly dated, but good discussion of “Why should I care about JPMS”.

[lefou]

Thank you both! I'm not so sure about the shortcuts regarding recompilation, since there may always be users who use the classpath. But it may be valid, if you only care about your local project. @froderick may I ask what build tool you use in that JPMS-enabled project?

[froderick]

My jpms project uses maven.