Drop Java 8 (JRE 1.8) support

[szysas]

Some reasons for moving project from Java 8 to Java 17 as minimum.

• Modernize Codebase:
  • Take advantage of language enhancements and new APIs introduced in Java 9 through Java 17 to keep the open-coap project modern and efficient
• Some Java 8 API became deprecated in 21
• Compiler Warnings:
  • warning: [options] source value 8 is obsolete and will be removed in a future release
  • warning: [options] target value 8 is obsolete and will be removed in a future release
• Library Compatibility:
  • Some libraries, like logback-classic and mockito-core, may not support Java 8 and it prevents using the latest versions.
• Gradle Plugin Compatibility:
  • Some Gradle plugins may not work with Java 8 - workaround is to use the toolchain feature in Gradle to specify the Java version for compiling and running the project.

References:

• https://www.oracle.com/java/technologies/java-se-support-roadmap.html
• https://adoptium.net/support/

[szysas]

@sbernard31 how big problem is that going to be if we drop java 8 support and use java 17 as minimum?

[sbernard31]

About Leshan project itself :

So nothing news on our side.

We decide that the minimal java version required will be java8 for Leshan 2.0.0 (in development version) : eclipse-leshan/leshan#924.

Reasons why we take this decision are still valid, so I don't think we will change this.

If there is good reason to jump to a more recent minimal java version requirement (I don't know maybe if when we release the stable version java8 is no more maintained?)), we could eventually consider Java 11 but not java 17. I don't see any good reason to use it from a Leshan consumer point of view. But again this is not planned at all to move to java 11.

Currently we are building Leshan using Java 11 and we produce java8 compatible binary, then we execute automatic test with all LTS version (8, 11, 17, 21)

Note that currently Californium v3 targets java 7 (the one used in Leshan 2.0.0) and v4 should target java8. (development doesn't start for now but we will sure integrate this version in Leshan 2.0.0 when available)

About java-coap integration in Leshan :

From user point of view, this is not so good as we need to explain that some part of Leshan will be compatible with java8 and other need java 17. (and maybe will not be compatible with Android?)

From Leshan developer, this could make build and test more complicated as we will need to adapt the code to build and test transport layer based on java-coap differently. (Hoping this will not force us to move to java 17 to build ...)

So from Leshan point of view this will not be a good news 😞

About java-coap itself :

What would be the reason to that move ?
What would be the benefit from user point of view ?

At first sight, it seems to me that reason which make us decide to use java8 as minimal should also lead to make java8 as minimal required version for java-coap but maybe I don't have the full big picture ?

[szysas]

I updated description with some reasons to do such a change. None of it seems like a blocker so we could go on with java 8 support.
If doing such a change, why do you think of choosing java 11 and not 17 if java 11 is out of support anyway?
Is there any way to test Android compatibility on API level? How do you verify that Leshan works with Android?

[sbernard31]

I updated description with some reasons to do such a change. None of it seems like a blocker so we could go on with java 8 support.

👍
If something change on our side, I will let you know !

If doing such a change, why do you think of choosing java 11 and not 17 if java 11 is out of support anyway?

I see java 11 supported until :

• January 2032 for Oracle
• At least Oct 2027 for Temurin

So I'm not sure I get your question ?
The idea is to provide compatibility with oldest JVM available to adapt to as many users as possible.

Is there any way to test Android compatibility on API level?

See : https://stackoverflow.com/questions/11048805/maven-plugin-for-checking-api-compliance-with-android/49153640#49153640

How do you verify that Leshan works with Android?

We don't really test it but I know some user succeed to make it works : https://github.com/eclipse-leshan/leshan/wiki/F.A.Q.#can-i-use-leshan-with-android-

I never develop for Android 😬

[sbernard31]

• Some Java 8 API became deprecated in 21

Is it API which could be easily removed in your case ?
Generally this is easy to replace by usage of different API : https://docs.oracle.com/en/java/javase/21/docs/api/deprecated-list.html

• Compiler Warnings:
  • warning: [options] source value 8 is obsolete and will be removed in a future release
  • warning: [options] target value 8 is obsolete and will be removed in a future release

I never see this warning, probably because I never build with java 21.
I guess this is not a big problem as long as there we can still compile with warning or we still maintained JDK.

• Library Compatibility:
  • Some libraries, like logback-classic and mockito-core, may not support Java 8 and it prevents using the latest versions.

For logback, I guess this is not an issue because logback-classic is not a compile dependencies, so users can use java-coap + recent logback + recent JVM.
For mockito-core, this is more annoying, mokito 4 still support java8 but v5 need java 11.

• Gradle Plugin Compatibility:
  • Some Gradle plugins may not work with Java 8 - workaround is to use the toolchain feature in Gradle to specify the Java version for compiling and running the project.

In maven you can build for java8 running java11 or upper without toolchain : see eclipse-leshan/leshan#1412
We are using toolchain only for testing on our nightly build, so not really used by contributor to build locally:

• https://github.com/eclipse-leshan/leshan/blob/master/.jenkins/nightly.jenkins
• https://ci.eclipse.org/leshan/job/leshan-nightly/

• Modernize Codebase:
  • Take advantage of language enhancements and new APIs introduced in Java 9 through Java 17 to keep the open-coap project modern and efficient

Yep could be frustrating sometime.
Do you identify some modern java features ?
Will those API exposed to users or will it be just for internal usage ?
About "efficiency", you talk about an easier way to produce and maintain code for java-coap team OR execution performance ?

[szysas]

Those reasons are minor, and like you pointed out there are workarounds. I still wanted to list them, and add later if something new comes up.