At the beginning of 2019, I wrote about the state of Java modularization. I took a sample of widespread libraries, and for each of them, I checked whether:
- It supports the module system i.e. it provides an automatic module name in the manifest
- It’s a full-fledged module i.e. it provides a
module-info
The results were interesting. 14 out of those 29 libraries supported the module system, while 2 were modules in their own right.
Nearly 2 years later, and with Java 16 looming around the corner, it’s time to update the report. I kept the same libraries and added Hazelcast and Hazelcast Jet. I’ve checked the latest version.
| Jan. 2019 | Oct. 2020 | |||||
|---|---|---|---|---|---|---|
Name |
Analyzed version |
Module name |
Modularized? |
Analyzed version |
Module name |
Modularized? |
1.8.0-beta2 |
|
1.8.0-beta4 |
||||
2.11.8 |
|
2.11.3 |
|
|||
2.8.5 |
2.8.6 |
|
||||
5.3.2 |
|
5.7.0 |
|
|||
2.23.4 |
|
3.5.15 |
|
|||
2.0.0-RC.4 |
2.0.7 |
|||||
3.8.1 |
|
3.11 |
|
|||
3.6.1 |
No new release |
|||||
27.0.1 |
|
30.0-jre |
|
|||
4.5.6 |
|
4.5.13 |
|
|||
2.12.0 |
No new release |
|||||
1.4.11.1 |
1.4.13 |
|||||
2.1.1 |
2.1.3 |
|||||
JAXB |
2.3.1 |
|
No new release |
|||
4.0.1 |
4.1.2 |
|||||
2.6.0 |
2.9.0 |
|
||||
2.1.1 |
|
2.2.3 |
|
|||
3.2.0 |
|
3.4.5 |
||||
2.5.0 |
2.8.0 |
|||||
5.5.13 |
5.5.13.2 |
|||||
2.3 |
2.5 |
|||||
4.2 |
|
4.4 |
|
|||
9.2.0 |
|
10.4.0 |
|
|||
3.1.0 |
No new release |
|||||
1.5 |
No new release |
|||||
1.11.3 |
|
1.13.1 |
|
|||
1.11 |
|
1.15 |
|
|||
3.8.1 |
3.9.1 |
|
||||
3.8.1 |
3.13.0 |
|
||||
First check |
4.0.1 |
|
||||
First check |
4.2 |
|
||||
Analysis
Oracle released Java 9 in September 2017.
Three full years after that release, 10 out of 31 libraries still don’t provide a module-compatible JAR.
Granted, 3 of them didn’t release a new version in the meantime.
That’s still 7 libraries that didn’t add a simple line of text in their MANIFEST.MF.
On the good side, Jackson, GSon, and Junit migrated to the module system. This is not a trivial effort and deserves some praise.
On the other side, SLF4J migrated back from the module system to an automatic module name. That’s an issue. If developers decide to use the module system and declare the dependencies of their app, they cannot upgrade libraries that follow this practice. I don’t know what to make out of it.
I checked the new v2 version (still in alpha), and it even has no Automatic-Module-Name.
Conclusion
Before writing this post, I assumed the penetration of JPMS in the ecosystem was close to none. I’m pleasantly surprised. However, while there’s progress, it’s slow. And modularizing your application if you have non-modularized dependencies is not trivial.
To go further:
- A hard look at the state of Java modularization
- Explicitly Naming Automatic Java Modules
- Migrating the ServiceLoader to the Java 9 module system
- Migrating a Spring Boot application to Java 9 - part 1
- Migrating a Spring Boot application to Java 9 - part 2
- Containerizing Apps with jlink
- ModiTect - Tooling for the Java Module System