Transition to new Java LTS versions. Ways of moving from applets

[malets12]

Java world continues evolution in 2020's: new LTS versions of JVM 17 and 21 were released.
JChemPaint uses Java Applets (java.applet.Applet) that are deprecated for removal since Java 9 and would be removed in near future.
Java 8 is also approaching to the end of life date (Eclipse Temurin and others).

Main goal of this discussion is to develop roadmap for smooth transition of JChemPaint packages to new (and upcoming) Java LTS versions.

[johnmay]

Agree we should probably remove the applet parts but I use Java 21 runtime and works great. So why remove the ability for older versions to run?

We are likely to move the Chemistry Development Kit to Java 17 at v3.0 release so it would not happen until then but I'm not really even convinced on that TBH.

[malets12]

IMHO: Applet API could be kept in separate branch only and marked as deprecated as well (to introduce more visibility), as motivation could be similar to JEP 398: "It is essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so." Other option: just mark it with @Deprecated in main branch.

About CDK, please guide, would it be more appropriate to create PR with Java 17-related changes to 3.0 branch or to main/other?

[johnmay]

About CDK, please guide, would it be more appropriate to create PR with Java 17-related changes to 3.0 branch or to main/other?

No and no. We have only just opened the 3.0 branch, we are still undecided whether to move to Java 17 or stay on Java 8. What do you think the advantages are?

[malets12]

OK, please let me know when you would be open for such contributions.
Advantages from top of my head:

1. More APIs for developers (which open ways to more productive apps). Of course, project Panama and Vector API are still in preview.
2. More efficient memory management: many optimizations of String.class (some available from Java 11), new GCs, etc.
   Some features have been used in https://github.com/gunnarmorling/1brc.
   And GraalVM-readiness.

[johnmay]

2. is runtime though... you can use the latest JVM and get a more efficient String and GCs without changing the library version. Likewise (beyond deprecated APIs) you can compile Java 8 "code" with GraalVM. It a minimum not a maximum.

[malets12]

2. Mostly yes, with some exceptions, like VarHandle API, SpinedBuffer for e.g. .toList() and others, they are not available in JDK 8 and open door to new VM parts and assembly-level optimizations.