Apache Derby target is byte code version 61

[georgweiss]

PR #2381 pulled in derby 10.16.1.1. This is built for class version 61, i.e. Java 17+. Will not run on Java 11.

[kasemir]

Yes, we updated derby in #2381 because of a dependabot warning.
We also have an open issue #2300 to generally try and reduce dependency vulnerabilities.

When I check the derby jar that I magically get via maven, that indeed seems to be a binary for Java 17 / major version 61:

javap -v 'jar:file:derbytools-10.16.1.1.jar!/org/apache/derby/jdbc/EmbeddedDriver.class'

Classfile jar:file:derbytools-10.16.1.1.jar!/org/apache/derby/jdbc/EmbeddedDriver.class
  Last modified Oct 31, 2022; size 1616 bytes
  SHA-256 checksum a270db1da00b3bc03e8505ac11d4e8b21b98b54393b845503b9bb7f018bf4604
  Compiled from "EmbeddedDriver.java"
public class org.apache.derby.jdbc.EmbeddedDriver implements java.sql.Driver
  minor version: 0
  major version: 61

If we don't use maven but fetch binaries from https://db.apache.org/derby/derby_downloads.html, the latest version also requires Java 17 or higher, so I don't think there's a way to get a binary for older JREs via maven, but Kunal has been having fun with using Java 8 for some libs and not others recently, maybe he has an idea.

The simple fix should be to run with Java 17 or higher. OpenJDK is currently at 18.

Alternatively, you could try to find a derby version between 10.14.1.0 as we used to have and the latest one that removes the dependency warning and still runs with older JREs. Like 10.15.2.0 looks like its binaries are for JDK 9, and should still fix the dependapot issue with 10.14.1.0.

With #2381, there was no change to any of our sources, just the derby version changed and unfortunately also the packaging as one jar vs. 3 jars.

[georgweiss]

Then I suggest to move all references (e.g. version variable in top level pom) to that module. Also suggest we add a README to state that scan server requires Java 17+ runtime.

[kasemir]

JavaFX 20 just came out which also requires JDK 17+

[georgweiss]

So the day has finally come... Guess sticking to JavaFX 19 to avoid JDK update is not acceptable.

Suggest we aim for a "final" release to Maven using version 4.x, then update JavaFX and JDK requirement and bump to 5.x. Assuming though that challenge lies in communicating this to stakeholders.

And then there is next LTS version (21) of Java, scheduled for Sep 2023.