Testing Java 17

[mokun]

Java Development Kit (JDK) 17 is slated to have the production version released tomorrow on September 14.

Since it's a long-term-support (LTS) release having extended support from Oracle expected for several years, most people are considering switching to it.

Shall we start planning our testing it to see how well it works with mars-sim ?

[mokun]

@bevans2000, @larsnaesbye , @Urwumpe ,

Anything in particular we need to be aware of ?

[Urwumpe]

I am still using 16 here, but I don't find much reason in the news about 17 to be especially careful. As legacy code, we should still be fine. The most important change that I see for our context are the new pseudo random number generators. The old APIs will remain, so no reason for urgency, but migrating to the new RandomGenerator API could still be a good idea for maintenance. See: https://openjdk.java.net/jeps/356

The vector API of Java 16 will still be incubating in Java 17. Sadly, this one could be really helpful in this context (rover motion, orbits, physical processes, etc.), since it allows a much higher performance when compiled into native SIMD code by the runtime. I don't think migrating to it is already worth the effort.

[mokun]

new pseudo random number generators

Will it be thread-safe ? Guess we can adopt that

[mokun]

I have concerns if Java 17 will block some of the reflection calls that weblaf needs and thus not compatible with mars-sim.

I cut and paste JEP 403 from this post as follows:

JEP 403: Strongly Encapsulate JDK Internals

As one of the primary goals of Project Jigsaw, JEP 403 proposes to strongly encapsulate all internal elements of the JDK, except for critical internal APIs, such as sun.misc.Unsafe, to improve the security and maintainability of the JDK. As the successor to JEP 396, Strongly Encapsulate JDK Internals by Default, it will no longer be possible to bypass strong encapsulation via the command-line option, --illegal-access, in Java 17. For example, attempting use this option by assigning the value permit will yield the following warning:

$ java --illegal-access=permit {filename}.java

OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit;
  support was removed in 17.0

[bevans2000]

How many people out there are going to adopt Java 17 in the first instance? Not many I would think at first so if the project makes Java 17 the minimum then it will exclude potential users. Also it is not widely available yet with AWS Corretto still only at 16.
The rework of Random is a benefit but not massive.

[Urwumpe]

I don't think you are still using any JDK internals in MSP. Should be an easy check.

But I agree, switching quickly to JDK 17 won't be helpful now. There is little to gain and much to lose.

[mokun]

I just downloaded oracle's official JDK 17 and unzipped it onto my machine.

For now, I'm using JDK 17 to compile it as the Java 11 level.

That's because I'm using Eclipse IDE (version 4.20.0). Even though it's the latest release version 2021-06, it does not support Java 17 compiler level yet.

Microsoft Windows [Version 10.0.19043.1165]
(c) Microsoft Corporation. All rights reserved.

C:\Users\mkhelios>java -version
openjdk version "17" 2021-09-14
OpenJDK Runtime Environment (build 17+35-2724)
OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)

D:\Data\msp binary\3.3.0>java -jar 6184.jar
      JAVA_HOME : D:\Data\java 2021\openjdk-17_windows-x64_bin\jdk-17\bin
   Java Command : "D:\Data\java 2021\openjdk-17_windows-x64_bin\jdk-17\bin\java"
Command: "D:\Data\java 2021\openjdk-17_windows-x64_bin\jdk-17\bin\java" -Xmx1536m
 --add-opens java.base/java.util=ALL-UNNAMED
 --add-opens java.base/java.text=ALL-UNNAMED
 --add-opens java.base/java.lang.reflect=ALL-UNNAMED
 --add-opens java.base/java.net=ALL-UNNAMED
 --add-opens java.base/java.lang=ALL-UNNAMED
 --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
 --add-opens java.desktop/javax.swing=ALL-UNNAMED
 --add-opens java.desktop/javax.swing.text=ALL-UNNAMED
 --add-opens java.desktop/java.awt.font=ALL-UNNAMED
 --add-opens java.desktop/java.awt.geom=ALL-UNNAMED
 --add-opens java.desktop/java.awt=ALL-UNNAMED
 --add-opens java.desktop/java.beans=ALL-UNNAMED
 --add-opens java.desktop/javax.swing.table=ALL-UNNAMED
 --add-opens java.desktop/com.sun.awt=ALL-UNNAMED
 --add-opens java.desktop/sun.awt=ALL-UNNAMED
 --add-opens java.desktop/sun.swing=ALL-UNNAMED
 --add-opens java.desktop/sun.font=ALL-UNNAMED
 --add-opens java.desktop/javax.swing.plaf.basic=ALL-UNNAMED
 --add-opens java.desktop/javax.swing.plaf.synth=ALL-UNNAMED
 --add-opens java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
 -Djava.util.logging.config.file=logging.properties -cp .;*;jars\* org.mars_sim.main.MarsProject -new
WARNING: package com.sun.awt not in java.desktop
2021-09-14T16:09:22.9 (Config) MarsProject : Starting Mars Simulation Project v3.3.0 - Build 6184 - 64-bit Java 17 - 8 CPU threads
2021-09-14T16:09:22.9 (Config) MarsProject : List of input args : [-new]
2021-09-14T16:09:23.3 (Config) SimulationConfig : The xml folder already existed.
2021-09-14T16:09:23.3 (Config) SimulationConfig : The version.txt has the same BUILD 6184 as the core engine's.
2021-09-14T16:09:24.1 (Config) SimulationConfig : Done loading all xml config files.
2021-09-14T16:09:24.1 (Config) MarsProject : Please go to the console's Main Menu to choose an option.
2021-09-14T16:09:40.0 (Config) SimulationBuilder : -----------------------------------------------------------
2021-09-14T16:09:40.0 (Config) SimulationBuilder :     Java Version Full String = 17+35-2724
2021-09-14T16:09:40.0 (Config) SimulationBuilder : Java Version Feature Element = 17
2021-09-14T16:09:40.0 (Config) SimulationBuilder : Java Version Interim Element = 0
2021-09-14T16:09:40.0 (Config) SimulationBuilder :   Java Patch Element Version = 0
2021-09-14T16:09:40.0 (Config) SimulationBuilder :  Java Update Element Version = 0
2021-09-14T16:09:40.0 (Config) SimulationBuilder :           Java Version Build = 35
2021-09-14T16:09:40.0 (Config) SimulationBuilder :   Java additional build Info = 2724
2021-09-14T16:09:40.0 (Config) SimulationBuilder :        Java Pre-Release Info = NA
2021-09-14T16:09:40.0 (Config) SimulationBuilder : -----------------------------------------------------------
2021-09-14T16:09:40.0 (Config) Simulation : Initiating the simulation core engine...
2021-09-14T16:09:40.1 (Config) MasterClock : -----------------------------------------------------
2021-09-14T16:09:40.1 (Config) MasterClock :                  Base time-ratio : 128x
2021-09-14T16:09:40.1 (Config) MasterClock :               Min msol per pulse : 0.02
2021-09-14T16:09:40.1 (Config) MasterClock :               Max msol per pulse : 2.0
2021-09-14T16:09:40.1 (Config) MasterClock :  Max elapsed time between pulses : 1000 ms
2021-09-14T16:09:40.1 (Config) MasterClock :                    Accuracy bias : 0.5
2021-09-14T16:09:40.1 (Config) MasterClock : -----------------------------------------------------
00-Adir-01:000.000 (Info) SimulationBuilder : Created default CrewConfig
00-Adir-01:000.000 (Severe) SimulationConfig : Cannot find the bundled XML /xml/defaults\crew_alpha.xml
00-Adir-01:000.000 (Severe) SimulationConfig : Cannot find the bundled XML /xml/defaults\crew_founders.xml
00-Adir-01:000.000 (Severe) SimulationConfig : Cannot find the bundled XML /xml/defaults\scenario_default.xml
00-Adir-01:000.000 (Config) SettlementBuilder : Scenario Default loading
00-Adir-01:000.000 (Config) SettlementBuilder : Creating New Plymouth based on template Phase 2-U
00-Adir-01:000.000 (Config) EVASuit :  EVA suit's unloaded weight : 14.15 kg
00-Adir-01:000.000 (Config) EVASuit :       Total gas tank volume : 3.9L
00-Adir-01:000.000 (Config) EVASuit :                Full Tank O2 : 66.62 kPa -> 1.0    kg - Maximum tank pressure
00-Adir-01:000.000 (Config) EVASuit :                  Nomimal O2 : 17.0  kPa -> 0.2552 kg - Suit target pressure
00-Adir-01:000.000 (Config) EVASuit :                  Minimum O2 : 11.94 kPa -> 0.1792 kg - Safety limit

So it works in this case as expected if compiled as Java 11 binaries.

We'll have to wait until the next version of Eclipse to come out that will enable the support of Java 17.

[bevans2000]

@mokun I think the latest version of Eclipse is supporting JDK19 now so we should reconsider moving to JDK17 as that's a good LSE.

[mokun]

So, there're two things we need to find out :

1. Can mars-sim v3.4.0 (or currently pre-3.5.0) be run under Java 17 ?
2. Can it be compiled under Java 17 ?

Note: the weblaf package may have issues with Java 17 if I remember correctly.

[bevans2000]

I've been using Java 17 for a few weeks now. The pom is still set to complier in 11 mode however.

[bevans2000]

I should have added I'm using VSCode not Eclipse and that's fine with Java 17.

[bevans2000]

I've done a full clean build in VSCode using Java17 and I now get some weird error.
java.lang.reflect.InaccessibleObjectException: Unable to make public static boolean sun.font.FontUtilities.fontSupportsDefaultEncoding(java.awt.Font) accessible: module java.desktop does not "exports sun.font" to unnamed module

It's a problem with weblaf . What are we going to do about it? Do we really need it ?

[Urwumpe]

I don't think we really need WebLAF. I think we use some features of it that are not just providing the look and feel of Java Swing, but we could either look for alternatives or try to change the UI to only use vanilla Swing components.

That missing reference to sun.* packages is a problem we will get on any non-Oracle JRE.

[mokun]

Yes we could get rid of weblaf and gradually replace with alternative replacement UI elements.

For now, if you see any WebLabel, WebPanel, etc., let's replace them with JLabel, JPanel.

In most part, the use of WebLabel and WebPanel won't matter much.

[bevans2000]

As this is now an issue #788 for users we should accelerate the java to Java 17. I'm going to create a branch based on the 3.4.1 release and work kn removing Weblaf. This gives us the option of a 3.4.2 release or roll it forward into 3.5.

[bevans2000]

#789

[bevans2000]

When are we going to jump to Java 17 now we have removed weblaf?

[mokun]

Are you currently using eclipse IDE ? I suppose older version doesn't support Java 17. Will need to download the latest version and reaccomplish the setup.

[bevans2000]

No I'm using VSCode now. I dropped Eclipse a long time ago as it was becoming too blotted.

[mokun]

No I'm using VSCode now. I dropped Eclipse a long time ago as it was becoming too blotted.

Can you put together a wiki page on how to set it up using vscode ?

I'd like to try that.

[bevans2000]

Sure, do we have a page for IDE setup? It's quite easy. I will, look into commiting my run configuration setup file.

[bevans2000]

Created #820

[mokun]

I've just downloaded the latest Eclipse 2023-03 version and Azul's Java 17 this morning.

Eclipse IDE reports a bunch of errors and still trying to get it to work.

I've also installed kotlin plug-in but it doesn't solve the problem. So it has to do with something else.

Question: does the javax.xml import work in UIConfig.java in mars-sim-ui ?

Mine doesn't work.

[mokun]

It said the package javax.xml is accessible from more than one module.

So it looks like it may have to do with module-info.java.

So I tried moving the line requires javax.xml around.

It's still not working.

[bevans2000]

Works for me using Corretto OpenJDK and also works for the GitFlow builds using Eclipse Temurin. These are both clean building using an OpenJDK.
I've installed nothing extra beyond my VSCode IDE and vanilla OpenJDK.
Never used Azul but I can try with Eclipse tomorrow.

[mokun]

Note that if we comment out the two builder.setProperty() calls, codesmell will report it as major security violation.

[bevans2000]

I've comment the 2 calls out and committed it, 8947f21
The problem is the java module logic not the libraries. javax.xml is available in OpenJDK.
Use a vanilla Eclipse with the embedded OpenJDK and it work for me.
It's not a massive Security problem but is it fairly easy to resolve.

[bevans2000]

The problem is with how Eclipse is handling the module-info logic with Java17. I have deleted all the module-info.java in my sandpit and Eclipse can do a full clean rebuild without problem. Also we can add the 2 set properties back in.
As we don't produce a JAR file that is use as a library; there is little benefit using the Java Module logic for us.
Do you want to delete the module-info files? As I said the build is working elsewhere; just seems to be how Eclipse is building.