Q: General upgrading gradle, Azul Java SDK, VS code support

[rondlh]

I upgraded gradle to version 8.13, which was quite easy and worked without any issues. I is supposed to improve the build speed, but I didn't notice much difference.
Q: Is this of interest to implement?

I also upgraded to the Azul Java SDK 23, which also seems to work fine, but more testing is required. It didn't solve the startup freeze issue.
Q: Is this of interest to implement?

Currently the project uses Azul Java 17, there is also an update available for it.

I managed to import the project into VS Code, this requires some changes in various build files, but nothing big.
Q: Do we want to support this? Which development environment is recommended?

[madhephaestus]

I generally use Eclipse, so just ensuring that the eclipse build is not broken is important to me. Adding VSCode sounds great and should help make the build easier for others to get involved.

As for the JVM and gradle builds, there are some extra steps that happen in CI that need to be checked such as the shadow jar and in the dependent repos, they get published as independent libraries. There are a few things to check when changing version numbers on gradle and the JVM.

As for updating the java 17 LTS version, that can be done in the jvm.json file in the project root. that file is added to each release and used by the auto-updater to allow the updater to also update the JVM with the jar file. Rev bumping that to the latest version ought to be safe.

You can test newer JVM's by hand editing the jvm.json in the downloaded directory of the current release to the latest version, even update to 23. That should let you check the latest version against the jvm. There are some internal loading operations that broke when i switched from 8 to 17 in the MuJoCo library, but that would not be easy to check in the current build. If the update actually fixed a bug (such as the startup freeze) then i would say its worth the risk and just do it, but if there is not an issue fixed by it, keeping the LTS jvm is slightly preferable.

[rondlh]

I generally use Eclipse, so just ensuring that the eclipse build is not broken is important to me.
OK, good to know.

Adding VSCode sounds great and should help make the build easier for others to get involved.
That is my point exactly.

I build the app with a newer Azul Java JDK, up to version 23. All seemed to work fine superficially. I did not do an extensive test.
I even tried Oracle Java 21 with the corresponding JavaFX 21. Works fine too, but also did not solve the startup freeze issue.

Update 17.62.17 is available for the currently used Azul 17.50.19 Java JDK. https://www.azul.com/downloads/?version=java-17-lts&os=ubuntu&package=jdk#zulu
It fixes a number of bugs.

As for updating the java 17 LTS version, that can be done in the jvm.json file in the project root. that file is added to each release and used by the auto-updater to allow the updater to also update the JVM with the jar file. Rev bumping that to the latest version ought to be safe.

You can test newer JVM's by hand editing the jvm.json in the downloaded directory of the current release to the latest version, even update to 23. That should let you check the latest version against the jvm. There are some internal loading operations that broke when i switched from 8 to 17 in the MuJoCo library, but that would not be easy to check in the current build. If the update actually fixed a bug (such as the startup freeze) then i would say its worth the risk and just do it, but if there is not an issue fixed by it, keeping the LTS jvm is slightly preferable.
I didn't know that, thanks!