I can't find anywhere a clear policy on which JDK versions are supported by RDF4J and how upgrades are handled. I suggest to define such a policy clearly in the documentation, to make it easier to understand for contributors and developers of downstream projects as to what they can expect in this regard.
My rough thoughts:
Official Docker images
This is probably the easiest – the images should probably just use the latest LTS JDK release – see #5608.
CI testing
I suggest to test with the oldest supported JDK, and either the newest LTS release, or the newest release in general. This is of secondary importance, though, because I imagine most features would still work on newer JDKs.
Minimum supported version
This is the tough one. See for example:
While I do understand that some stakeholders want to stick to Java 11, this is holding back progress in the library for everyone else. Java 11 was released over 7 years ago and since then many features were added that could greatly benefit the project (e.g., records, better switches, foreign memory API, vector API, virtual threads, flexible constructors and more). I'm personally of the opinion that if large corporate stakeholders want to maintain a Java 11 version of RDF4J, they have the necessary resources to do so, and should not rely on the community to provide that support.
Java has switched to a much faster release cadence, so jumping on the train of modern JDK releases would mean a new LTS JDK exactly every 2 years. This puts a clear tempo on the ecosystem and provides an incentive to get rid of dependencies that are not maintained anymore (e.g., Solr).
Jena has moved to Java 17 in 5.0: https://lists.apache.org/thread/hn1d1mpg9hwv7m0m620j53jgpw2rrdyz – from what I remember they planned to tie major releases with LTS releases of the JDK, so that Jena 6 would release with a JDK 21 requirement next year.
Lucene 10 requires Java 21: https://lucene.apache.org/core/10_3_2/SYSTEM_REQUIREMENTS.html
Lucene in particular is a good example here, because it's also performance-focused like RDF4J. Lucene has made good use of the new Java features like FFM and Vector APIs (they get regularly mentioned in talks by Oracle as a poster child of modern Java), which would also be useful in RDF4J.
I think personally that RDF4J 6 should move to JDK 21 (and be released in early 2026). This would put RDF4J on par with Jena. I would be very happy if RDF4J could at least keep up with using "one LTS release back", like Jena. But this is coming from a newcomer to the RDF4J community, so please take it with a grain of salt...
I can't find anywhere a clear policy on which JDK versions are supported by RDF4J and how upgrades are handled. I suggest to define such a policy clearly in the documentation, to make it easier to understand for contributors and developers of downstream projects as to what they can expect in this regard.
My rough thoughts:
Official Docker images
This is probably the easiest – the images should probably just use the latest LTS JDK release – see #5608.
CI testing
I suggest to test with the oldest supported JDK, and either the newest LTS release, or the newest release in general. This is of secondary importance, though, because I imagine most features would still work on newer JDKs.
Minimum supported version
This is the tough one. See for example:
While I do understand that some stakeholders want to stick to Java 11, this is holding back progress in the library for everyone else. Java 11 was released over 7 years ago and since then many features were added that could greatly benefit the project (e.g., records, better switches, foreign memory API, vector API, virtual threads, flexible constructors and more). I'm personally of the opinion that if large corporate stakeholders want to maintain a Java 11 version of RDF4J, they have the necessary resources to do so, and should not rely on the community to provide that support.
Java has switched to a much faster release cadence, so jumping on the train of modern JDK releases would mean a new LTS JDK exactly every 2 years. This puts a clear tempo on the ecosystem and provides an incentive to get rid of dependencies that are not maintained anymore (e.g., Solr).
Jena has moved to Java 17 in 5.0: https://lists.apache.org/thread/hn1d1mpg9hwv7m0m620j53jgpw2rrdyz – from what I remember they planned to tie major releases with LTS releases of the JDK, so that Jena 6 would release with a JDK 21 requirement next year.
Lucene 10 requires Java 21: https://lucene.apache.org/core/10_3_2/SYSTEM_REQUIREMENTS.html
Lucene in particular is a good example here, because it's also performance-focused like RDF4J. Lucene has made good use of the new Java features like FFM and Vector APIs (they get regularly mentioned in talks by Oracle as a poster child of modern Java), which would also be useful in RDF4J.
I think personally that RDF4J 6 should move to JDK 21 (and be released in early 2026). This would put RDF4J on par with Jena. I would be very happy if RDF4J could at least keep up with using "one LTS release back", like Jena. But this is coming from a newcomer to the RDF4J community, so please take it with a grain of salt...