Migrating Choco-solver to Java 11 (or even 17)

[cprudhom]

I'm considering moving from Hava 8 to Java 11 (or 17) for the source code and the compiled .class files.
Indeed, even though Java 8 will be supported until December 2030, I believe the code can benefit from a more recent version.
That would lead to a major release of Choco.

[jgFages]

Hi, it is a good question indeed.
On my side, I am impressed by the reliability of Java 8 whereas I sometimes have JVM crashes - some kinds of seg fault - on Java 11 OpenJDK distribution (on both Mac and Windows)...

[dimitri-justeau]

I don't know whether there are fundamental differences in stability and performance between Java 11, 17, or 8. However, if Java's new version provides helpful features and syntax elements for Choco, I would be in favour of migrating Choco to newer Java versions. Indeed, installing a newer Java version is straightforward in every OS, so if it brings improvement to developers and users I don't see why we shouldn't do it (and the current version of Choco will remain compatible with Java 8).

[cprudhom]

I observe that some dependencies (like ANTLR or JGrapht) are moving to 11 and we are stuck to "old" version since there is no backward compatibilities. Actually, this is the major drawback, from choco's users side, to have to move to J11 or get stuck to J8 and a freeze version. About VM behavior, I can't testify.
On the other hand, moving to 11 or 17 will first offer better coding opportunities :)

Note that the three versions (8, 11 and 17) are LTS.

[cprudhom]

I'm bringing this up again. Adding another LTS: version 25.
Btw, the Project Valhalla is in early-access and could be available soon... :)

[jgFages]

In which version are we currently? 16?
I would recommend moving to java 17, or possibly 21 but no further.

[ArthurGodet]

@jgFages No, we are currently in Java 8 (but needing Java 9 to compile due to the use of modules). I agree not going too far (Java 25 is too young to be a target for us imho), but I think that Java 17 might be a good target for us.

[cprudhom]

Well, the maven-compiler-plugin is configured to compile everything with JKD9 to ensure module-info contains right entries.
Then, the code is recompiled everything for JDK8 except the module-info.java.
So, the code is officially on 8 but support 9.

In my opinion, among LTS:

• jdk11: already outdated in some ways
• jdk25: too early

The choice must be made between 17 and 21.

Here is a small summary of features that might impact/improve the library (there may others I don't know):

Feature / Area	Java 8	Java 17
Data Classes	Verbose POJOs (Getters/Setters)	Records
Hierarchy	Open by default	Sealed Classes
Logic	Classic switch & instanceof	Switch Expressions & Pattern Matching
Garbage Collector	ParallelGC (Default)	G1GC (Default) / Low-latency ZGC

and:

Feature / Area	Java 17	Java 21
Concurrency	Platform Threads (OS-heavy)	Virtual Threads (Project Loom)
Switch Logic	Basic Pattern Matching	Pattern Matching for Switch
Collections	Inconsistent ordering API	Sequenced Collections (standardized getFirst()/getLast())
Performance	Standard G1/ZGC	Generational ZGC

I think we can move to 17 and consider upgrading more regularly (say, every two years) to a newer LTS version.

[jgFages]

What is this for in the solver pom.xml ?

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>16</source>
                    <target>16</target>
                </configuration>
            </plugin>

[cprudhom]

I think this is a bad commit.
However, based on the generated file (javap -v Model.class) after a call to mvn clean compile:

  minor version: 0
  major version: 52

the release code is Java 8.

So, at this point, we can consider that this plugin is ignored (by the way, this argues in favor of standardizing the configuration.)

[jgFages]

I prefer Java 17 :

• we won't benefit from most new features anyway because it would imply rewriting the code, which is not an option
• Many projects are still in Java 17 and upgrading it implies costly updates (spring, security, hibernate, etc.) and regression risks.

[ArthurGodet]

One can argue that whatever the LTS we choose, we won't rewrite all the code.

That said, I am for moving to Java 17 too for the same reasons : major Java projects such as Spring are in Java 17, and it is a good target to be compatible with these projects