The road to Java 17

Robert Varga

Hello everyone,

as you might have noticed, Java 17 has been released: with reference implementation here:

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:
- (switch expressions)
- (hidden classes)
- (text blocks)
- (instanceof pattern matching)
- (records)
- (sealed classes)
- (deserialization filters)
- (improved CHA)

Furthermore, there are a ton of runtime improvements, which we can take into implementation considerations, like 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.


Join to automatically receive all group messages.