Java 17 support

[r3n4ud]

Hello,

The current master failed to build with OpenJDK 17.

A first issue is the JaCoCo version (0.8.5 seems incompatible with Java 17) -> Updating it to 0.8.7.
The next issue is a little bit trickier since it involves xstream:

[...]
[ERROR] gate.xml.TestXml.testAnnotationConsistencyForSaveAsXml  Time elapsed: 0.011 s  <<< ERROR!
com.thoughtworks.xstream.converters.ConversionException: 
No converter available
---- Debugging information ----
message             : No converter available
type                : java.util.Arrays$ArrayList
converter           : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
message[1]          : Unable to make field protected transient int java.util.AbstractList.modCount accessible: module java.base does not "opens java.util" to unnamed module @64a294a6
-------------------------------
[...]

For reference:

• Fails on Java 16 for java.util.Arrays$ArrayList and java.util.Collections$EmptyList x-stream/xstream#253
• Java 17 - Unable to make field protected transient int java.util.AbstractList.modCount accessible x-stream/xstream#259
• How much longer for XStream? x-stream/xstream#262
• https://github.com/gama-platform/gama/issues/3288

A workaround to get the tests go green is to add the following --add-opens to pom.xml:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.0.0-M8</version>
  <configuration>
    <argLine>
      --add-opens java.base/java.util=ALL-UNNAMED
    </argLine>
  </configuration>
</plugin>

I assume add --add-opens java.base/java.util=ALL-UNNAMED to the java -jar call will do at runtime.

Any plans to support Java 17?

[ianroberts]

Currently the minimum JDK requirement for GATE is Java 8 and therefore the CI and release builds must be run on Java 8 and we can't add options like --add-opens to the pom as those are not understood by Java 8. So building gate-core on Java 17 is out of scope but I agree that allowing it to run correctly on Java 17 is worth doing if that isn't already the case.

Adding different JVM options depending what version of java we're running on is easy enough to do for Linux and Mac (where the launcher is a shell script) but much more difficult on Windows (where the launcher is an exe wrapper created using Launch4J). We'd either have to have the installer generate a different l4j.ini depending on the Java version (and document the required changes for people who are "installing" from the zip distro rather than running the installer) or switch to a different exe generator if we can find one that supports conditional argument sets.