Migrate to Java 11 as minimal requirement for RDF4J

[abrokenjester]

Currently, RDF4J is built and guaranteed compatible with Java 8.

However, newer versions of Java offer significant advantages, both in terms of quicker runtime performance, as well as features that offer benefits for the project's development. I'm think of support for modules, in particular, as part of our effort to stabilize our public API (see #619).

I'm opening this issue to solicit opinions early on the pros and cons to having our next major version bump the minimal version of Java straight to version 11 (going with 11 as it is the LTS release).

Some notes:

1. If we bump versions for the next major release (say 4.0.0), we will for the medium term continue to do patch releases for 3.x.y in parallel - which will of course remain compatible with Java 8.
2. it is an open question whether continued maintenance for 3.x.y will also include further minor releases (that is, adding new functionality), or only patches/bug fixes.

I'm looking for opinions on whether our users, and third party implementors, are ready to make this jump. My personal opinion is that bumping JVM versions is a lot more acceptable in enterprise these days than it was in the days of Java 7 and 8.

[barthanssens]

JDK11 LTS for a 4.0 sounds reasonable to me. I'm beginning to see migrations from 8 to 11 LTS in not-so-fast-moving organizations (YMMV), and IIRC public / free JDK8 updates from Oracle will probably end this December.

[hmottestad]

We would appreciate comments from the following who are mentioned on our website: https://rdf4j.org/about/

• Ontotext GraphDB
• Halyard
• Stardog
• Amazon Neptune
• Systap Blazegraph
• MarkLogic RDF4J API
• Strabon
• Openlink Virtuoso RDF4J Provider

If you know someone who represents one of the above, it would be great if you could invite them to this discussion.

[barthanssens]

I've sent a tweet to Ontotext, Stardog and SemanticWebCompany

[barthanssens]

Response from ontotext (https://twitter.com/vassil_momtchev/status/1244548895893524482?s=20)

"Ironically Java 8 will outlive 11 in the enterprises. (see https://adoptopenjdk.net/support.html). Sadly from a developer's perspective, I don't think it's a good idea to drop the JDK8 support yet."

[vassilmomtchev]

The official policy in Ontotext is:

• Keep compliant with OpenJDK
• Support Java 8 and 11 + all next LTS versions (I see no new releases on the horizon)
• Make the best effort to stay compliant with all other versions, although I would discourage in using them because they will become very soon out of support

By default, the GraphDB Free native installer is shipped with Adopt OpenJDK 11, although the majority of the existing clients are still on Java 8.

[abrokenjester]

Good to know, thanks for your input @vassilmomtchev . Just to be clear: RDF4J is currently kept compatible with Java 8-11 (and we're looking to change that to 8-13). This proposal is about moving that minimum boundary up to 11 in a future major release (not necessarily the next one - I haven't proposed a timeline yet). The main benefit this would give us is that we can start using the module system, plus the fact that there have been many useful new additions to the platform that we might potentially exploit for better performance.

I do believe that in the end we have a duty to convince our users that such benefits outweigh the risks of upgrading.

That said I agree with you that we can't just drop Java 8 support next week, and your comments reinforce that we will need to support Java 8 in some fashion in the foreseeable future.

[hmottestad]

At my office I have dropped all use of Java 8. I'm currently on 13 for most of my projects and try to keep up to date with the newest versions. Feeling I get from other people is that old projects are still stuck on java 8, new projects are either java 11 or the latests version of java 13/14.

[hmottestad]

Even though Stardog hasn't joined this discussion I can see that their newest release now finally supports Java 11. It still supports 8, so it's not a hard switch for them.

[hmottestad]

Release date the next LTS of Java (17) is set for September 2021.

I propose that we drop Java 8 support at that point and move to Java 11 for our next major release and keep a branch around for the previous major release and do bug fixes on an ad-hoc basis. I believe that users who are unable to move past Java 8 for some reason are unlikely to be able to update their RDF4J dependency. At that point we would be maintaining backwards compatibility with a Java version release 7 years ago.

Another note is the progress of project Valhalla. Valhalla is likely to deliver a massive performance boost to data structures and I foresee a lot of database vendors taking advantage of this. That would probably be a driving force for people to upgrade.

I also wonder what Apache Jena is planning. Anyone know?

[barthanssens]

AFAIK Jena is still JDK8, though also doing CI testing on 11 and 14. We could of course just ask them on the Jena mailinglist to be sure :-)

[hmottestad]

Found something interesting for us.

When GC is taken into account, sorting of IRIs in the MemoryStore is more than 6x faster in Java 11 compared to Java 8. (See: https://github.com/eclipse/rdf4j/pull/2562)

[hmottestad]

I'm wondering if it might be time to reevaluate our choice of sticking with Java 8. It would be very interesting to see if it's enough for users to just use Java 11+ and get all the benefits or if we need to compile the code to Java 11 for everything to be optimal.

I'll look into it.

I propose that based on the results we either:

1. Start actively pushing users to Java 11+ by recommending it over Java 8 in our documentation
2. Look into having releases with multiple compiled versions of the same library

And I would anyway recommend we move all development to Java 11+, while keeping ourselves compatible with 8. Eg. we as developers use Java 11+ on our dev machines but set the language feature version in our IDEs to Java 8 so we don't use any new APIs or new language features.

[abrokenjester]

Look into having releases with multiple compiled versions of the same library

If it turns out that the code needs to be compiled with Java 11 to get these performance benefits, then what we could set up is a separate "backport" release process that uses Java 8 to compile and produce release artifacts that are still Java 8-compatible. We can publish these using a specific suffix on the artifact version number: "4.0.0-jdk8" . The default version "4.0.0" could then require Java 11 at a minimum.

Of course this approach will still mean that we can't use any Java 11 features in our code base. If we want that and still offer some backward compatibility, the only alternative is to go for a completely separate backport branch in git for Java 8, and make sure it's kept up to do with the main (Java 11) branches, rewriting incompatible language features as we go. Laborious, but possible (we did this for a while for Java 7).

And I would anyway recommend we move all development to Java 11+, while keeping ourselves compatible with 8. Eg. we as developers use Java 11+ on our dev machines but set the language feature version in our IDEs to Java 8 so we don't use any new APIs or new language features.

Good idea.

Fwiw our maven build process currently has checks in place to make sure that the code we produce is Java 8-compatible, and should fail if you try using Java 11 features in the source. But tweaking your IDE is a good idea regardless :)

[abrokenjester]

There's a couple of dependency issues that need to be fixed, in relation to certain javax.xml packages that were included as separate dependencies but are now part of the JDK system api, causing duplicate module errors in Eclipse.