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:

• 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

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