What Java Modules Are About

I agree it hasn’t gotten adoption, but you get a pretty slim JVM if you properly modularize. Another poster in this thread said he got his image down to 30mb.

Helidon is probably the only library I know that is modularized [0].

I think once the community finally moves past jdk 8 (I’m hoping spring making 17 the base next year will help) we’ll see more adoption as more libraries modularize.

[0] https://github.com/oracle/helidon

Half agreed, but, there are some mitigating things to consider.

One is that native code is really verbose compared to bytecode, and jlink optimizes bytecode to shrink it when it's modularized (collapses the string tables and other things). For tiny hello world apps native-image can produce smaller downloads. It doesn't take long before a jlinked JVM is smaller, because the JIT compiler is kind of "decompressing" native code on the fly. A minimal jlinked JVM can be small-ish, like 20mb or less, and if you compile a custom JVM with configure flags for size it can be even smaller still. The smallest jlinked hello world I managed to get when I tried this was a 7mb download. Not small for a program that only prints something, but, obviously, most of that is one time cost.

Another is that jlink+modules is way easier to use and configure than native-image. Tree shaking breaks stuff all over the place. You end up needing complex config files, agent-based config auto generation and/or lots of runtime testing to ensure you got everything. The point of "reliable configuration" is to avoid all this by building a less aggressive form of tree shaking into the language itself.

Quite a few libraries support modules at this point, but you may not actually have noticed. It depends on your build tool and things.

One thing that's slowed it down is that a lot of widely used libraries that sit at the bottom of the dependency stack aren't actually well maintained. And, modules can only depend on other modules. SLF4J, Guava etc have been slowing things down a lot.

My feeling is that the module system is kind of underrated and waiting for better tooling to be fully exploited. Quite a few parts of Java are like this. Like, it took quite some years for the ecosystem to start using annotation processors to full advantage, and some popular libraries still have it as a pending feature (like PicoCLI).

> Everyone still downloads and runs an entire JVM.

They do? I work in the Scandinavian public sector and we abandoned Java two or three years ago because of the continued security issues it posed. Software that require an install JVM to operate doesn’t get past our IT department.

I’m not sure modules would help though, as I don’t know much about them. But not everyone still installs JVM.

Here the list of all modules on Maven Central https://github.com/sormuras/modules/blob/main/com.github.sor...

> Everyone still downloads and runs an entire JVM

Nope, we (i know anecdote) use jlink in docker containers, mostly to avoid useless dependencies. The problem of GraalVM native image is that it comes with a subpar GC.

> which broke plenty of Java applications

yes, i agree, modules did not worth the trouble.

Java modules haven't been adopted because people are still getting off of JDK 8 as it becomes deprecated.

It will only make sense for library and framework maintainers to invest in modules once there is a large user base on JDK 11.

Either way, modules are still useful for application development. I used them years ago to close off internal APIs in one of my applications, which helped me to not cross levels of abstraction accidentally.

> All that work, which broke plenty of Java applications, violating main Java mantra of backward compatibility, all for nothing.

How did modules break Java applications? Having recently upgraded a number of applications from 8 to 11, none of the things we had to fix were due to modules. They were largely due to libraries relying on internal implementation details of Java 8 which needed dealing with, the exact sort of thing that modules are looking to prevent going forwards (see "strong encapsulation" in TFA).

We've ignored modules so far with no issues.

IMO the main issue with modules is that strong encapsulation is actually a bad goal. If the focus was solely on reliable configuration, I think that the transition would have gone better.

WRT why I think strong encapsulation is a bad goal: I've worked extensively in .net where assembly-private members are the norm for core libraries. It has issues. Classes and methods that are theoretically extensible aren't so in practice because core logic is inaccessible.

In the end, encapsulation, no matter how strong, doesn't prevent people from relying on internal implementation details. If the concern is people relying on "internal" APIs, either suck it up and make those APIs public (with all that entails) or come up with a deprecation strategy (or just freeze them and refactor around them).

1. The breaking of some libraries in JDK 9 had very little to do with modules and was mostly due to weak encapsulation. Almost all issues stemmed from libraries, written to be non-portable, hacking into JDK internals and becoming entangled with the particulars of JDK 8. When those internals changed, they broke. With modules' strong encapsulation now finally enabled, this won't happen again. In other words, modules weren't the cause of the breakages, but added to prevent them in the future. Unfortunately, they were blamed for the problems they were created to prevent because they were the most famous feature in JDK 9.

2. Modules are becoming the core of Java's security strategy. Without them, your code only does what you think it does unless any library decides it should do something else.

3. The reduction of security and maintenance concerns have already yielded tremendous dividends, as we the JDK developers have been freed to work on other stuff. Your complaint is like someone finally getting a fast internet connection, saying, all that noise and dirt of tearing up the street putting in the cable ducts have been in vain; they should have just given us fast internet, because that's all we wanted.

So, we've got better security and a drastic reduction in future breakages, all for negligible backward-incompatible changes to the spec.

This article explains it well, code examples included: https://www.baeldung.com/java-9-modularity

You did not elaborated what frustrated you about classpath. So it hard to answer.

My first experience with the JVM classpath was when I started using Clojure with zero Java experience. I quickly understood it more or less works the same as UNIX $PATH (although the devil is in the details, they are not identical), and since then I haven't really hit any issues. nodejs/npm does something similar by instead of being user set by default, it defaults to "./node_modules && ./node_modules/*/node_modules" (recursively).

Most languages deal with paths in mostly similar ways (except Go until recently). What precisely is your issues with the Java classpath that someone who have been writing Clojure code for years haven't hit yet?

I've had the opposite experience. The classpath system in java is, in my experience and opinion, one of the better packaging/module discovery systems among all of the languages I've ever tried.

Modules fix two issues that plagues Java for a long time, classpath resolution and monkey patching using reflection.

For the former, the classpath is a colon separated list of jars (a zip containing the classes). At runtime the VM tries to find a class by scanning linearly all the jars, when needed or panic with a NoClassDefFoundError. The modulepath is a colon separated list of directories that contains some jars. At runtime, the VM revolves the dependencies (stored in the module descriptor of each jar) before starting the application.

For the later, when you define a module you have to explicitly export packages and open them to reflection

Moduler are almost completely orthogonal to the classpath; nothing changes for the latter. They are meant more as a way to enforce encapsulation. For example, runtime reflection is disallowed through module boundaries.

From the JDK’s point of view it was really important, because some libs were depending on the internals of the OpenJDK, which are prone to change. With modules enforced, the internals can change much more liberally, while still keeping up perfectly with backwards compatibility.

Well, if you use maven or gradle, it will manage the classpath for you. If you are doing this manually, you indeed need to read up on how that works. It isn't particularly hard. It's like a file path; but for class and jar files. It pretty much works the same way. Where the class loading mechanism gets complicated is the notion that it's a run-time thing and that Java allows for loading and unloading things at runtime as well as loading jars and classes into separate class loaders that can each have their own copies of the same; or even different versions of class files. Not a lot of applications actually do that these days but it used to be quite common.

I actually used OSGI back in the day (a more powerful module system) that relied on this for managing different components that each had their own dependencies and dependency versions. Neat, but no longer that common to do these days. Osgi actually emerged out of the embedded software devices world. Later Eclipse used it to componentize the Eclipse platform and I know some companies that use OSGi for different things. These days you'd use microservices in some kind of Kubernetes container; or not (I'd consider that overkill for most of the stuff I work on).

The Java module system is much simpler and not really intended for this (at least not primarily). Instead, the main use case is ahead of time compilation. Modules allow parking things that can't be compiled (e.g. because of reflection ahead of time in separate modules, which you can then exclude. Breaking up the jvm platform into modules was a big project. As far as I know, they are not that commonly used for anything else. At least, I've not encountered many projects that rely on this. It's a pretty low level mechanism.

These days for servers, you package up applications as Docker containers, which contain your application and the full jdk. Both Spring Boot, Ktor, and other modern frameworks are commonly packaged up as single jar applications. Nothing magical about that; they are literally zip files with some manifest listing their content (classes, resources, more jar files). Of course modularizing a single jar application is kind of pointless. Likewise, there is no real need to tweak the java runtime you run it with either. Just not a thing. The notion of stuffing zip files in zipfiles is also a bit weird but it kind of works as a packaging mechanism.

The Java classpath is "flat" by default: you can only have one version of any given class (and therefore de facto only one version of any given library, unless they move the library to a different package for each major version, which some libraries do) on the classpath. This has advantages: you avoid the Rust problem of "Foo is incompatible with Foo" because you had two different versions of Foo in your (transitive) dependencies. But it means that if some library you're using uses a utility library internally, that dependency "leaks" and "pollutes" your classpath: you can't use a different version of that utility library yourself.

Modules try to solve this by distinguishing between exported and internal dependencies. The idea is that if your library depends on some other library and uses that as part of its API, that should be an exported dependency (and a program that uses your library has to use the same version of that). But if your library depends on another library just for internal implementation, that gets hidden away from the application that uses your library.

Personally I'm extremely doubtful of this working, because for it to work, library authors would have to specify their metadata correctly. So I suspect it's only going to lead to bigger problems than before, as the classpath gets more complicated and there are more ways to go wrong. But we'll see.

It doesn't depend on modules. And in fact, you don't even have to wait until runtime and throw an exception: plugins like https://github.com/basepom/duplicate-finder-maven-plugin/wik... can enforce this at build time, with neat features like allowing two classes with the same name as long as their contents are 100% identical, or allowing specific exceptions where you can confirm they aren't going to cause problems.

We run this plugin where I work. We have no plans to modularize our build since the duplicate class protection would just be worse that this plugin.

This is an implementation problem. For performance reasons, the JVM doesn't scan the entire classpath - when a Class object has to be created (to access one of it's members for the first time, such as a constructor or static method), some class loader is asked to scan the classpath until it finds that class (.class file, in .jar or directly on disk). This stops after the first successful find.

This is also a reason why you can't use regular Java reflection to do something like finding all references to a method, or even finding all classes - classes are loaded on the fly, only as needed (there are libraries that modify this behavior, though).

If these JARs are on the module path, this problem would be spotted at compile time, resulting in a failure due to the "split package" situation which has been created by having that class in more than one JAR.

Yep, I have a JavaFX GUI which is fairly complex, and the jlink image it creates is less than 30MB. Notice that this includes all my code, JavaFX, the JVM runtime and even Swing (even though I don't use Swing, it needs to be included for stuff like splash screen and some platform features, unfortunately).

Usually one way is to have your own classloader for example.

jar signing has been around at least since Java 6 if I recall correctly: https://docs.oracle.com/javase/tutorial/deployment/jar/signi...