Article originally posted on InfoQ. Visit InfoQ

In a mail to the Java Champions list, Martijn Verburg, leader of the London Java Community announced:

We want to identify where popular libraries are falling behind with regards to working on Java 9+ and then which are using the modularity system in a minimal (automatic modules) or full manner.

The LJC has already announced a crowdfunding project, aimed at “Funding Java OSS in order to minimise a Java 8/9+ split”, and the new community effort will help shape the crowd funding goals of the LJC’s campaign.

The effort is being supported by several Java Champions, including: Sander Mak, Ray Tsung, Robert Schulte and Rabea Gransberger and have launched a survey asking as many Java developers as possible to participate and gain a better understanding of actual practice.

InfoQ spoke to Martijn Verburg about the campaign:

InfoQ: Why did you launch the new campaign? Are there specific issues that you’ve seen from within the community that you feel the vendors are not addressing?

Verburg: We launched this campaign because of the changes that came with Java 9 which require significant code changes to some libraries and frameworks, and the new release cadence for Java, which again will require some libraries and frameworks to make changes in order to remain compatible.
      
The changes in Java 9 and the new release cadence have been clearly communicated by Oracle for some time and there has also been lot of work done in conjunction with them to upgrade popular libraries and frameworks.

However, we believe that there are still a large number which are not working correctly on Java 9 and / or will struggle to keep up with the new release cadence due to a small maintainer / volunteer base or lack of commercial backing.

So we want to identify those projects and help them become compatible so that applications can rely on popular libraries and frameworks when migrating.

InfoQ: Have you already identified any major Java technologies that potentially have problems moving to modules?

Verburg: This is really a 3 part question:

1. Does the major technology run on Java 9/10?

Quite a lot of major technology does.  For example, IntelliJ does, Apache Maven does (with changes to your POM), JUnit 5 does, Spring 5 has support and so forth.  However, there are notable omissions.  

Java EE / Jakarta EE does not out of the box, there are several Apache common’s libraries that are still working on adding proper support and so forth.

We’re going to scan through Maven central and apply a bunch of tests to see what percentage (of popular projects in particular) are compatible or not.  We suspect that it’s fairly decent and growing at a steady rate.

2. Does the major technology run on the modulepath by using an Automatic-Module-Name?

We’ll have a better answer when we complete the data mining of Maven Central, but we suspect this is a small but growing number.

3. Does the major technology wholly embrace the module system by using module-info.java?

Again, we’ll have a better answer when we complete the data mining of Maven Central, but we suspect this is a small number which is growing slowly. Oracle and most of us anticipated this, proper modularity is hard!

InfoQ: What about automatic modules? Do you think that they provide a viable long-term solution for libraries, or should they be seen as more of a stop-gap?

Verburg: They were meant to be a stop gap, but my personal fear is that since programmers default to ‘lazy’ that most library and framework maintainers will simply add this and not worry about modularising their application using the module system (and gaining the benefits of that).

I personally think there needs to be more best practice and tooling support to help day to day developers make difficult modularity design decisions and refactoring. If the popular dependencies that we all rely on modularise fully, then we may well see applications following suit, else it’s unlikely.

The module system is clearly a big win for the JDK itself and for vendors that can utilise the derived smaller custom packaging features. However, it may not get broad mindshare or usage from the day to day app developer, only time will tell.

InfoQ: Do you have a sense of whether the Java community is facing a “Python 2/3 problem”?

Verburg: I think we are going to see a bit of a Python 2/3 challenge for Java and there are two reasons for this:

1.) The effort with moving all common / popular dependencies to be Java 9+ compatible. This is clearly a solvable problem and one we can speed up with the crowdfunding efforts described earlier.

2.) An unknown market reaction to Oracle’s LTS support plan for Oracle’s JDK. As a reminder public updates will finish after 6 months even for an LTS release. After that if you wish to stay on that Oracle LTS release and get security and stability fixes you will have to pay for support from Oracle (for the Oracle JDK), else you’ll have to move to Java 12 after that 6 month window and so forth.

The Java 9 adoption survey is open now and everyone is encouraged to participate.