What Java version are you on?

[abrokenjester]

We'd love to get a feeling for what version of Java users of RDF4J are at, typically. Whether you're using the RDF4J Workbench/Server tools, or whether you're using the libraries. So here's a little non-scientific poll: we'd like to hear what the required version of Java in your project is. If it's acceptable to use several versions in your project, pick the most recent one.

Also: we'd love to hear some background on what your project is and why you use the version of Java you use. Feel free to comment.

[barthanssens]

Most application still on JDK 11 but slowly migrating to JDK 17 LTS, new applications slowly using JDK 17 as default.
Containers (with vendor-supported images for JDK 11 and JDK 17) help a lot in managing versions, by the way...

Non-LTS versions are a bit of a no-no: most code is actually version 11(-ish), no need for latest and greatest language features, mainly using new JVM for a (slight) increase of perfomance and to be "future-proof"

[abrokenjester]

That all sounds very sensible. What (if anything) are you finding to be the biggest concerns/roadblocks when migrating any app to a newer Java version?

[barthanssens]

In general it's not for technical but for business reasons

For business-critical (especially when running in an application server) applications it's about support / certification of the whole stack by the vendor (e.g. a commercial tool is only certified to run on a set of OS with a specific VM) + testing to check if an application still works on a newer JVM (occasionally it doesn't), combined with sysadmin resources to support other apps .

I.e. sysadmins (for good reasons) want to limit the number of different systems, so if apps A and B runs on v11 only, they might not be too keen on using v17 for (even unrelated) apps X and Y. Especially since they can get the same question for versions of PHP, Python, NodeJS...

In "devops"-style containerization, the responsibility is mostly shifted towards other people (though the issue for standardization remains), and often these applications are using libraries / frameworks that already support newer JDKs in the first place.

That being said, IMHO I do think JDK17 for a new major RDF4J release would be a good thing.

[knoan]

On 28 Sep 2022, at 22:11, Jeen Broekstra ***@***.***> wrote: That all sounds very sensible. What (if anything) are you finding to be the biggest concerns/roadblocks when migrating any app to a newer Java version?

Things like obscure dependencies breaking on introspection being blocked by tighter module-based encapsulation…

…

---- alessandro bollini - ingegnere via cavallotti 9, 27100 pavia, italy

[knoan]

On 28 Sep 2022, at 11:47, Bart Hanssens ***@***.***> wrote: Most application still on JDK 11 but slowly migrating to JDK 17 LTS, new applications slowly using JDK 17 as default. Containers (with vendor-supported images for JDK 11 and JDK 17) help a lot in managing versions, by the way... Non-LTS versions are a bit of a no-no: most code is actually version 11(-ish), no need for latest and greatest language features, mainly using new JVM for a (slight) increase of perfomance and to be "future-proof"

Same situation here.

…

----------------------------------------------------------------------------------------------------------------------------------------- alessandro bollini ph.d. - tech lead - linkedin.com/in/alessandrobollini


[JervenBolleman]

We have few Java11 because machine is rhel/cent-os 7 and that does not have a redhat provided Java 17 build. All new projects are deployed on Java 17 and tested on latest (dnf info java-latest-openjdk, currently 19).

Public projects are sparql.uniprot.org, sparql.rhea-db.org, sparql.swisslipids.org.