The road to Java 17


Robert Varga
 

On 25/09/2021 00:00, Robert Varga wrote:
Hello everyone,
Hello again,

as you might have noticed, Java 17 has been released: https://jdk.java.net/17/ with reference implementation here: https://jdk.java.net/java-se-ri/17
[snip]

IIUC, there are only a few issues which prevents us from adopting JDK 17 as a requirement:
- maven-xtend-plugin compatibility (due to Guice, what a surprise), which should be solved in 2.26.0, whenever that is available
- SpotBugs compatibility, which should be addressed in 4.4.x series
These issues have been addressed.

With all this in picture, I believe the proper course in OpenDaylight is to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with artifacts compatible with JDK11+
- All of Sulfur being validated with JDK17
Both these items are delivered, all projects participating on Sulfur GA verify each patch with both JDK11 and JDK17.

- Chlorine (22.09) to require JDK17+
This is now slated for delivery: odlparent/master and yangtools/master both require JDK17 and are taking advantage of JDK17 features. More projects are slated to follow.

Regards,
Robert


Robert Varga
 

Hello everyone,

as you might have noticed, Java 17 has been released: https://jdk.java.net/17/ with reference implementation here: https://jdk.java.net/java-se-ri/17

OpenDaylight currently requires Java 11 at compile-time and *should* be able to run on everything up to Java 17. This *should* is currently not enforced by our CI, but I am not aware of any reasons this would not be the case.

Java 17 is the next LTS release, which there are multiple support options available, with at least 8 years of support being available.

As per our usual OpenDaylight support policy, we are currently supporting Java 17 runtime on a best-effort policy: any issues found will be dealt with to the extent considered feasible.

Going forward, though, we will require Java 17 as both compile-time and runtime very soon, simply because of the language feature options becoming available:
- https://openjdk.java.net/jeps/361 (switch expressions)
- https://openjdk.java.net/jeps/371 (hidden classes)
- https://openjdk.java.net/jeps/378 (text blocks)
- https://openjdk.java.net/jeps/394 (instanceof pattern matching)
- https://openjdk.java.net/jeps/395 (records)
- https://openjdk.java.net/jeps/409 (sealed classes)
- https://openjdk.java.net/jeps/415 (deserialization filters)
- https://jdk.java.net/17/release-notes#JDK-8251989 (improved CHA)

Furthermore, there are a ton of runtime improvements, which we can take into implementation considerations, like https://bugs.openjdk.java.net/browse/JDK-8266074. We want to take advantage to these ASAP.

IIUC, there are only a few issues which prevents us from adopting JDK 17 as a requirement:
- maven-xtend-plugin compatibility (due to Guice, what a surprise), which should be solved in 2.26.0, whenever that is available
- SpotBugs compatibility, which should be addressed in 4.4.x series


With all this in picture, I believe the proper course in OpenDaylight is to have:
- Sulfur (22.03) supporting both JDK11 and JDK17 at compile-time, with artifacts compatible with JDK11+
- All of Sulfur being validated with JDK17
- Chlorine (22.09) to require JDK17+

Unless there are any objections, this is the current plan of record. If you disagree, please holler now.

Regards,
Robert