Java Modules

After reading the Java 9 modularity book by Sander Mak and Paul Bakker (excellent book btw), I was wondering how many Java libraries already had been migrated to Java 9 modules. I couldn’t find much about it, except for Stephen Colebourne’s Module names for Java SE 9. Even though it’s more focussed on module naming, it contains a markdown table that mentions a number of migrated libraries (40, with 30 from one project). But it didn’t completely answer my question, so I wondered if I shouldn’t do some research myself and (“how hard can it be?”) started writing a script that gets jars from maven central and checks their Java 9 module status. Because I didn’t fancy the idea of entering lots of maven coordinates of libraries I knew, I started with a few well-known ones and extracted the dependencies from the pom file to discover more. It took some coding effort (which made me realise again that when something isn’t hard, that doesn’t necessarily mean it’s not a lot of work ;-)), but it worked out pretty well. Even though I only started with a list of 15 to 20 libraries, the script resulted in more than 4000 (!) libraries being checked.

59 Java Modules

The results were somewhat disappointing: i found only 59 Java modules. On a total of 4527, that’s only 1,3%! It seems we must conclude that adoption of the Java 9 Module system is still very limited.

Automatic modules

But maybe that is a premature or unfair conclusion. First of all, in this list there are 534 that have explicitly set the “Automatic Module Name” in their manifest. So you might argue that at least the library maintainers put some effort in making their library ready for use in a modular Java application. Taking these into account leads to an adaption figure of 13% – 10 times better then my first conclusion.

Dead libraries

Next, even though the script always obtains the latest version of a library, there is of course a number of libraries that is too old, that is not maintained anymore, for example because they are superseded by something new (jboss -> wildfly) or just got new maven coordinates (tomcat -> org.apache.tomcat). It wouldn’t be fair to count them as “still not migrated”, as they probably never will. I should only check libraries that are “new enough”; using the date that Java 9 was released seems the logical thing to do.

Filtering my list of libraries on being updated after Sept 22, 2017, the figures are:
– modules: 53
– defined automatic modulde name: 530
– total number of libraries: 2756
So 1,9% is a real Java module, and 21% is “module ready”. The latter is much better than the 13% we got before, but the 1,9% for real modules is still not very impressive.

(B.t.w., did you notice the number of modules is less then before? Apparently, some libraries where already migrated before Java 9 was released; I guess there are people who are enthusiastic about the Java 9 module system ;-))

Libraries or artifacts

The last thing to consider is that while I was talking about libraries, I should have used the term “artifacts”. I don’t think there is a formal definition of “library”, but I think most people would agree with me that a library can (and often will) consist of several artifacts. So an interesting question is what the figures will be when we take this into account.

Unfortunately, there is no easy way to regcognize which artifacts belong to which library. But what we can do, is measure against maven group id’s; it’s likely that artifacts within one group somehow form a project and are update / migrated together. Counting maven group-id’s, the figures are:
– modules: 22
– defined automatic modulde name: 130
– total number of libraries: 684
resulting in: 3,2% real modules, 22% “module ready”.

Even though the percentage of real modules has increased with 50%, it’s still not much, is it?

Modularity is key

May be I should have known better after I’d discovered Stephen Colebourne’s list, but I think the results are disappointing. And it makes me a bit sad, because I think that creating modular software is important in order for it to be and stay maintainable. At Luminis we have always believed (and still do) that OSGi is an excellent framework for writing modular code and I think that Java 9 modules is a nice addition in the field of modularity that fits nicely for systems that don’t require the dynamic nature that OSGi supports so nicely. I wonder whether the low adoption rate indicates indifference, or that the library maintainers are just to busy with other priorities.

But let’s end positive: there are quite some library maintainers that did put effort in support Java 9 modules, and we should appreciate that. Let’s send them some kudos: pick some from the list and tweet that you’re glad they made it a module!

Tweet about this on TwitterShare on LinkedIn

Reacties

Het e-mailadres wordt niet gepubliceerd.

*