DEV Community

Cover image for Update on the state of Java modularization
Nicolas Fränkel
Nicolas Fränkel

Posted on • Originally published at blog.frankel.ch

Update on the state of Java modularization

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:

  1. It supports the module system i.e. it provides an automatic module name in the manifest
  2. 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?
SLF4J 1.8.0-beta2 org.slf4j 1.8.0-beta4
Jackson 2.11.8 com.fasterxml.jackson.core 2.11.3 com.fasterxml.jackson.core
GSon 2.8.5 2.8.6 com.google.gson
JUnit 5.3.2 org.junit.jupiter.api 5.7.0 org.junit.jupiter.api
Mockito 2.23.4 org.mockito 3.5.15 org.mockito
PowerMock 2.0.0-RC.4 2.0.7
Commons Lang 3.8.1 org.apache.commons.lang3 3.11 org.apache.commons.lang3
Commons Math 3.6.1 No new release
Guava 27.0.1 com.google.common 30.0-jre com.google.common
Http Client 4.5.6 org.apache.httpcomponents.httpclient 4.5.13 org.apache.httpcomponents.httpclient
Xerces 2 2.12.0 No new release
XStream 1.4.11.1 1.4.13
dom4j 2.1.1 2.1.3
JAXB 2.3.1 java.xml.bind No new release
Apache POI 4.0.1 4.1.2
Commons Pool 2.6.0 2.9.0 org.apache.commons.pool2
Flexipool 2.1.1 com.vladmihalcea.flexypool.core 2.2.3 com.vladmihalcea.flexypool.core
HikariCP 3.2.0 com.zaxxer.hikari 3.4.5
Commons DBCP 2.5.0 2.8.0
 iText 5.5.13 5.5.13.2
FOP 2.3 2.5
Commons Collections 4.2 org.apache.commons.collections4 4.4 org.apache.commons.collections4
Eclipse Collections 9.2.0 org.eclipse.collections.api 10.4.0 org.eclipse.collections.api
Trove 3.1.0 No new release
Commons Email 1.5 No new release
JSoup 1.11.3 org.jsoup 1.13.1 org.jsoup
Commons Codec 1.11 org.apache.commons.codec 1.15 org.apache.commons.codec
P6Spy 3.8.1 3.9.1 p6spy
ProtoBuf 3.8.1 3.13.0 com.google.protobuf
Hazelcast First check 4.0.1 com.hazelcast.core
Hazelcast Jet First check 4.2 com.hazelcast.jet

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:

Originally published at A Java Geek on October 25th, 2020

Top comments (0)