Move to JDK 8 as minimum runtie JDK and JDK 9+ as build JDK

[matthiasblaesing]

• Compilation of JNA and JNA platform was modified to use the javac --release flag with a value of 8. The bytecode level and thus minimum runtime JDK is raised to 8.
• Generated build script for JNA platform was dropped in favor of a build.xml modeled after the JNA one. NetBeans integration was moved from Java Project to Java Freeform Project (this was already the case for JNA)

[dblock]

Does it make sense to call this 6.0?

[dblock]

Does it make sense to do a major version increment to 6.0 and follow semver after that?

[dbwiddis]

Does it make sense to do a major version increment to 6.0 and follow semver after that?

+1 on the major version increment, and I thought we were already following semver.

[matthiasblaesing]

From my POV a clear -1 on the version change. This version is API and ABI compatible with prior releases. It just does not run on ancient JDKs anymore. I you are still running on a JDK < 8, you have other reasons to be concerned and must expect every library release to break compatibility. I assume, that 99.99999% of all users will not notice any difference between 5.13.0 and 5.14.0.

For the semver thing: Yes we are there. The last screw up was inside the 4.X series, where incompatible changes were made without bumping major version.

[dblock]

From my POV a clear -1 on the version change. This version is API and ABI compatible with prior releases. It just does not run on ancient JDKs anymore.

So you claim this doesn't break semver? I can surely get along with that because JDK .... 6 but if you were dropping JDK 8 I would probably feel otherwise! :)

Here's a conversation about exactly this topic: semver/semver#534 (comment). It's pretty clear that this is semver-breaking.

[dbwiddis]

Well, I have never changed to Java 8 support on a minor version bump. https://github.com/oshi/oshi/blob/master/CHANGELOG.md#25-2016-04-06. Oops, maybe I have.

…

On Thu, Oct 5, 2023 at 11:24 AM Daniel (dB.) Doubrovkine < ***@***.***> wrote: From my POV a clear -1 on the version change. This version is API and ABI compatible with prior releases. It just does not run on ancient JDKs anymore. So you claim this doesn't break semver? I can surely get along with that :) — Reply to this email directly, view it on GitHub <#1554 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACG4PN6QUUMYUH65XRHIISDX533NTAVCNFSM6AAAAAA5Q55336VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBZGQZDSMJUG4> . You are receiving this because you commented.Message ID: ***@***.***>

-- Dan Widdis

[matthiasblaesing]

So I ran JNA 5.13.0 JAR and 5.14.0-SNAPSHOT build from this branch through japi-compliance-checker. Report:

compat_report.zip

The "problem" being reported can be ignored, as the constant USE_VARARGS is an implementation detail, that touches the JNA Java<->native ABI, but not external users. The report for the platform looks worse, but is actually not. The errors reported there are interfaces additions, that would be incompatible in regular java applications, but JNA binds to native, not Java, ignoring that, we are also clean there.