Drop Java 1.8 support?

[Thrameos]

Java 1.8 should have gone the way of the dodo long ago. We should move our target to JDK 17. Java 1.8 is a completely different beast lacking module support and requiring a different calling mechanism entirely. It would be a small matter to drop it from build matrix, move our jar target to JDK 11 and then I can delete all the legacy code.

Thoughts?

[Thrameos]

This appears to be a bit more critical that I hoped. In order to use JavaFX it appears that I have to convert org.jpype into a module as the classloader must be from within a module to run properly. Java 1.8 is going to interfere with this process. On the other hand I don't want to leave 1.8 on a busted version. It seems like the right solution is to release 1.5.2 then release 1.6 with Java 1.8 dropped and new module support.

It is not entirely clear whether dropping 1.8 is necessary. It is just that maven which I am trying to use to build the jar file which is very unhappy with the process of building such a mixed mode jar. On the other hand adding module support to JPype pretty much necessitates dropping Java 1.8 as it lacks these features and we are quickly going to be in a case where someone trying to run 1.8 is going to get a host of wierd errors. I would rather just have one consistent failure mode "Java 1.8 is no longer supported" than a dozen different errors.

@marscher thoughts?

[astrelsky]

If you do drop jdk 8 support, it may be worth investigating replacing the proxy reference queue with java.lang.ref.Cleaner.

[tim-littlefair]

I expect the contributors have already considered this, but the old 'Binary Code License for Java SE' only applies to versions of Java SE released prior to April 16 2019, so there may be a fair amount of code out there in the wild which was developed between 1996 (JDK 1.0 released) and 2019 when this license or earlier similarly permissive ones applied to current Java.

The BCL includes the sentence:

"Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs."

The BCL contains some vague restrictions in relation to "COMMERCIAL FEATURES" which limit the scope of statement above, but my understanding has always been that Java SE applications built against a BCL-licensed JDK version could be distributed freely without payment or audit obligations, alongside the runtime required to execute them, and the JDK required to support and develop such an application can be distributed freely within development teams engaged in that task.

For Oracle Java versions released since April 16 2019, (including updates to Java SE 8 released after that date) there have been more complex requirements, which are effective in dragging everyone who uses Oracle vendor Java into an obligation to submit to audit for a licensing fee based on the headcount of the enterprise, however few employees

Oracle have done their best to make it hard to find downloads of JDK versions available under the BCL terms, but my understanding is that updates up to and including update 202 of Java SE 1.8 are still usable and distributable under BCL (see the StackOverflow reference below, although the Oracle link from that page to the SDK download now returns a page related to 'Autovue Enterprise Visualization Systems').

Java 8 update 202 or earlier are very old, and very vulnerable SDK, and I wouldn't advocate anybody using them in an application which is currently in regular production use or continued maintenance, but I was personally in a situation a couple of years ago where I needed to make some changes to extend an infrequently used application written around 2000 which was designed to bootstrap and maintain a series of small, offline per-customer databases in a proprietary format used to generate security payloads for a distributed system including cloud and IOT elements. The database editor application consisted of a complex tree-based Java Swing UI making calls to a Java business engine which wrapped a complex body of code from a proprietary C library, and had been updated to use JavaSE 1.8 update 45 last time maintenance was required some years earlier. I was able to use jpype very successfully to build a simulation of the operation of the operation of the Swing UI to drive the business engine, so that I could have an automated test to reliably reproduce a sequence of about 40 tree-navigation, right-click, edit-attribute operations required for the bootstrap and payload generation phases and have an automated test which enabled me to ensure that the payload set generated would meet requirements when deployed to the live customer environment.

Of course I could have updated the application to use one of the alternative non-Oracle JDK platforms which now exist, but before I had an automated test in place I wanted to avoid a platform change.

So just a thought, no longer a consideration for me, but maybe there are other jpype users who are license-bound on 1.8 or earlier.

References:

• https://www.oracle.com/au/java/technologies/javase/jdk-faqs.html
• https://stackoverflow.com/questions/58250782/which-free-version-of-java-can-i-use-for-production-environments-and-or-commerci

[Thrameos]

I understand the issue with the license, though I think that Oracle dominance of the platform is fading. Restricting our feature set to 1.8 is most certainly hampering the development. At best we would have to fork the project to have a version that supports 1.8 and another for modern features. As the reflection API has different requirements it more than doubles the development time of many features. (how to make it work in 1.8, how to make it work in 9, how to get the two implementations to play nice with each other, nope... try another formulation.)

My work site has yanked 1.8 and is actively uninstalling Java versions prior to JDK 17 from machines, meaning that ;the act of installing a 1.8 copy to test on, means my machine will be booted from the trust domain as being out of compliance with our security plans. (Not sure how Matlab users are going to survive, I assume they must be granting some kind of exception.) That is a fairly large impediment to development going forward.

So which is more valuable at this point? JPype continuing to support an out-of-date and increasingly hard to find version, or having support for modern JVM features and potently switching from JNI to a more direct interaction which will be supported going forward?

[astrelsky]

I understand the issue with the license, though I think that Oracle dominance of the platform is fading. Restricting our feature set to 1.8 is most certainly hampering the development. At best we would have to fork the project to have a version that supports 1.8 and another for modern features. As the reflection API has different requirements it more than doubles the development time of many features. (how to make it work in 1.8, how to make it work in 9, how to get the two implementations to play nice with each other, nope... try another formulation.)

My work site has yanked 1.8 and is actively uninstalling Java versions prior to JDK 17 from machines, meaning that ;the act of installing a 1.8 copy to test on, means my machine will be booted from the trust domain as being out of compliance with our security plans. (Not sure how Matlab users are going to survive, I assume they must be granting some kind of exception.) That is a fairly large impediment to development going forward.

So which is more valuable at this point? JPype continuing to support an out-of-date and increasingly hard to find version, or having support for modern JVM features and potently switching from JNI to a more direct interaction which will be supported going forward?

I'm most likely going to get some crap for this but I'll say it anyway. Java 8 was released in March 2014. That was almost 11 years ago. If they haven't upgraded it since then, I highly doubt they have any interest in updating Jpype.