/ JIGSAW, MODULES, MODULARIZATION, JPMS

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.

Nicolas Fränkel

Nicolas Fränkel

Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Also double as a trainer and triples as a book author.

Read More
Update on the state of Java modularization
Share this