Migrate from Java 17 to 21

[EwoutH]

Java 21 LTS has now been release for 6 months, which may be a good time to see if we can start upgrading to Java 21. This PR tests that by updating the pom.xml and the GitHub Actions workflows to use Java 21 LTS instead of Java 17 LTS.

The previous Java upgrade was done and discussed here:

• migrate from Java 11 to 17 #2043

Potentially interesting articles:

• Upgrading From Java 17 To 21: All You Need To Know
• What’s New Between Java 17 and Java 21?

New features in JDK 18, 19, 20 and 21 are:

JDK 18

• 400: UTF-8 by Default
• 408: Simple Web Server
• 413: Code Snippets in Java API Documentation
• 416: Reimplement Core Reflection with Method Handles
• 417: Vector API (Third Incubator)
• 418: Internet-Address Resolution SPI
• 419: Foreign Function & Memory API (Second Incubator)
• 420: Pattern Matching for switch (Second Preview)
• 421: Deprecate Finalization for Removal

JDK 19

• 405: Record Patterns (Preview)
• 422: Linux/RISC-V Port
• 424: Foreign Function & Memory API (Preview)
• 425: Virtual Threads (Preview)
• 426: Vector API (Fourth Incubator)
• 427: Pattern Matching for switch (Third Preview)
• 428: Structured Concurrency (Incubator)

JDK 20

• 429: Scoped Values (Incubator)
• 432: Record Patterns (Second Preview)
• 433: Pattern Matching for switch (Fourth Preview)
• 434: Foreign Function & Memory API (Second Preview)
• 436: Virtual Threads (Second Preview)
• 437: Structured Concurrency (Second Incubator)
• 438: Vector API (Fifth Incubator)

JDK 21

• 430: String Templates (Preview)
• 431: Sequenced Collections
• 439: Generational ZGC
• 440: Record Patterns
• 441: Pattern Matching for switch
• 442: Foreign Function & Memory API (Third Preview)
• 443: Unnamed Patterns and Variables (Preview)
• 444: Virtual Threads
• 445: Unnamed Classes and Instance Main Methods (Preview)
• 446: Scoped Values (Preview)
• 448: Vector API (Sixth Incubator)
• 449: Deprecate the Windows 32-bit x86 Port for Removal
• 451: Prepare to Disallow the Dynamic Loading of Agents
• 452: Key Encapsulation Mechanism API
• 453: Structured Concurrency (Preview)

[EwoutH]

Most tests are already passing, it seems that only drt-extensions and simwrapper currently fail.

[rakow]

Please try again after PR #3126 has been merged.

[EwoutH]

All checks pass!

@michalmac, since you lead the migration from Java 11 to 17, could you give this PR a review?

[michalmac]

Thanks! Looks good to me.

This PR means that the upcoming yearly release will require Java 21. I cannot say if this is good or not for teaching matsim. If not, we should wait out with merging until the yearly release is out. @kainagel what is your opinion?

This change will need to get propagated to dependant repos. I do not think this is an issue.

[michalmac]

Any 👍 or 👎 on merging this PR now?

[rakow]

Our server infrastructure does not have java 21 installed at the moment. Please wait until we had time to switch. I guess others will also need time to adapt.

[EwoutH]

Maybe we can establish a target date to switch to Java 21? With whom should we coordinate/communicate about this?

[Janekdererste]

We could wait until after the yearly release (end of March) and then switch java versions on the development branch. This way, downstream projects only have to switch versions if they depend on a more recent MATSim version than the next release. This would save us from switching many downstream projects at once.

Downstream projects can always use more recent Java versions than what their dependencies require, so there is no time pressure from that side.

In the matsim-libs project, we would have the new version available in approximately six weeks.

@EwoutH Is there a specific reason that you need the newer version?

[EwoutH]

Switching after the yearly release sounds reasonable. No specific reason, just seemed about time.

[paulheinr]

Our server infrastructure does not have java 21 installed at the moment. Please wait until we had time to switch. I guess others will also need time to adapt.

Java 21 is now installed on the math cluster. But I agree, let's switch after the release.

[EwoutH]

An argument for switching before could be that Java 21 is supported for two more years over Java 17, making simulations built now be supported longer and possible future migrations easier. And it's nice to be able to use the latest features (okay, not the very latest, because JDK 22 just released, but still), when developing.

I think the main question is, if there's enough time to properly test it before the stable release.

[michalmac]

An argument for switching before could be that Java 21 is supported for two more years over Java 17, making simulations built now be supported longer and possible future migrations easier. And it's nice to be able to use the latest features (okay, not the very latest, because JDK 22 just released, but still), when developing.

It works a bit different. By setting the Java version to 17, we mean the bytecode will be built against version 17 (Java 17 language + public API). It can be run on any JDK 17+.

[paulheinr]

Since the new release is published, should we now switch to java 21?

[Janekdererste]

Since the new release is published, should we now switch to java 21?

I don't see why not. Who wants to do this? We then have to migrate downstream projects as well, in case they are using recent matsim versions

[paulheinr]

Since the original PR was created from a forked repository, I created a new one: #3238

[EwoutH]

If (still) necessary I can rebase this branch.