Building for JDK9+ - Githubissues

I noticed that JDK 8 is still needed for building. Is this intentional? Do you plan to support JDK 8 in the java-client? I'm looking at some warnings like:

[WARNING] /home/peter/work/git/tikv-client-java/src/main/java/org/tikv/common/util/MemoryUtil.java:[31,16] sun.misc.Cleaner is internal proprietary API and may be removed in a future release
[WARNING] /home/peter/work/git/tikv-client-java/src/main/java/org/tikv/common/util/MemoryUtil.java:[32,16] sun.misc.Unsafe is internal proprietary API and may be removed in a future release
[WARNING] /home/peter/work/git/tikv-client-java/src/main/java/org/tikv/common/util/MemoryUtil.java:[33,18] sun.nio.ch.DirectBuffer is internal proprietary API and may be removed in a future release
[WARNING] /home/peter/work/git/tikv-client-java/src/main/java/org/tikv/common/util/FastByteComparisons.java:[23,16] sun.misc.Unsafe is internal proprietary API and may be removed in a future release

There are alternatives in JDK 9+ that don't produce such warnings which are now runtime errors in JDK 16+... How much do you value being able to run on JDK 8 ? There is an option of creating alternative classes such as MemoryUtil for JDK 8 vs. JDK 9+ and pack them into a multi-release JAR which would run correctly across all the JDK 8, 9, ..., 16+ releases. I can try to do that and propose a PR if you're interested. The prerequisite for doing that is to require JDK 9+ (preferably JDK 11) to build the project via maven. The javac would use -release 8 option then to build most of the code so it would run on JDK 8, only those classes that need to use different API in JDK 9+ would then be build using -release 9 option. At the end the multi-release JAR would be build which would use the correct classes for the platform on which it is running. Are you OK with that approach?

That would be a really nice idea to support other Java versions! You see, before the client was separated from TiSpark, we require Java 8 so that users do not struggle with incompatible Java versions.

So are you OK with approach to require JDK9+ (or even JDK 11) for building client-java while the produced jar would still work on JDK 8 ?

I think there is always a way to build with JDK8 along with other Java versions... and it does not break the current environment. Let's try to fulfill them both while supporting more Java versions:)

The problem is that a build produced with JDK 8 javac will:

produce runtime warnings when run on JDK9...15
fail on JDK16+

Because it uses deprecated (encapsulated) JDK APIs which are deprecated for removal (in JDK 16 they are just disabled, but JDK 17 might remove them alltogether) You see, building with JDK 8 can't build code that uses replacement API(s) introduced in JDK9+. OTOH when building with JDK 9, you can use the -release 8 javac option that does the following:

it produces bytecode compatible with JDK 8 runtime
it checks that only API(s) present in JDK 8 runtime are used in compiled code

so building with JDK 9 javac with -release 8 option is quivalent to building with JDK 8 javac. If you want to build alternative versions of classes like MemoryUtil where one version will be used when running on JDK 8 and the other version when running on JDK 9+ (using multirelease JAR), then only JDK 9 javac is suitable for that. Unless maven pom.xml is structured in a way where building a multirelease (and thus JDK 8+ compatible JAR) would be performed only when a particular Maven profile is enabled. So by default building with JDK 8 would not enable the profile, but building with JDK 9+ would enable it. Is this acceptable?

I see, it seems logical to me. We could discuss this change in our meeting with other client contributors. If it is okay, I can schedule it next week. Also, this change would influence a lot that it may not be merged to release 3.x. We could consider it to be enclosed in the next big release, say release-4.0?

I'm going to try to modify the build procedure to use a Maven profile which would be enabled manually. I think this way default build procedure can be left unchanged so the impact is minimal. You can choose to include that in either 3.x or 4.0 if you think the change is suitable for inclusion. Perhaps in 4.0 the profile could be enabled automatically when building with JDK 9+ but in 3.x only manually?

tikv / sig-transaction

Building for JDK9+ #104