BT

Java Community Aims to Quantify Java 9 Adoption

| by Ben Evans Follow 31 Followers on Jun 22, 2018. Estimated reading time: 4 minutes |

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?

Martijn 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 three 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 are 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 who 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 six 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 six month window and so forth.

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

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Java 9 changes weren't well communicated by Christo Zietsman

32-bit builds were made available up until the last early access build. It was even available for download if you could guess the URL from the download site for RTM. Even .NET Core has support for it but not Java.

No they did not communicate Java 9 changes well!

"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."

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT