Nightly build failed for Mac

[davidhutchens]

Our nightly build 1103 failed on the Mac build three days ago. It could not find Java 16. The available versions are 11, 17, 18, 19, 20, 21, and 22. It looks like they dropped support for Java 16. Java 11, 17, and 21 are LTS releases. I think we should upgrade our java version.

We need to move to at least 17, but I think we should consider moving to 21. We have code that can be cleaned up if we go to at least Java 20. Specifically, we added support for 16-bit floating point components in PR #1878 and included methods to perform calculations with it. Java 20 supports 16-bit floats so we could eliminate those methods.

As noted above, the current release is Java 22, so Java 21 is not quite the bleeding edge. Java 21 was released last September. So there has been time for tools to fully incorporate it. Both Eclipse and IntelliJ should work with it. I check our code with each release as it comes out, and I am currently compiling with Java 22, so we should have no problems with Java 21.

Please let me know if I should proceed with a PR and which version you would recommend.

[maehne]

I agree with your suggestion to require from now on at least Java 21 LTS for our code base. I am looking forward to reviewing your PRs in that direction!

[davidhutchens]

I have verified that I can use Eclipse 2024-03 (latest release) with our main branch with Java 21. I have also similarly used the latest release of IntelliJ. I also checked that Microsoft provides the AARCH64 build of Java 21 so we can build the Windows arm64 version when we make the next release.

[MarcinOrlowski]

What about availability of Java 21 runtime in major distros?

[maehne]

@MarcinOrlowski:

What about availability of Java 21 runtime in major distros?

IMHO, we shouldn't be too concerned about that, as the JRE gets bundled with the application when building the DEB or RPM package. The JDK is only required for building the application.

JDK 21 is available for all major distributions, e.g., through Eclipse Temurin.

[davidhutchens]

Nightly failed to upload some files after the Java 21 upgrade. This sounds like bad news, but the reason it failed is that Github has changed the macos-latest runner to run on an aarch64 (M processsor) Mac. It actually built the aarch64 version but we were looking for the x86_64 version name for the upload. That means we can now build the nightly for both x86_64 and aarch64. I am preparing a PR to do that.

There was also a failure to upload the .deb file. Apparently the folks writing Java's jpackage utility decided to remove the "-1" revision indicator from the .deb filename and we were looking for it to be there. I checked to see if it is acceptable to leave that off. The best I could find was a note saying the reason for the "-1" is to indicate that someone downstream repackaged the product, presumably without changing the version. That suggests we really shouldn't actually put that "-1" in the file name. So my PR will upload the file jpackage is producing without any attempt to rename it to include the "-1".

I noticed from all these issues with uploading and filenames that it might be nice to check to see if we are actually generating what we expect in build.gradle.kts. So I added code to generate a warning if the generated file isn't named what we expect and to add to the warning a list of the files it finds in the dist directory. I tried this in a testProject to determine what we were actually generating for the .deb file and found it handy.

I should have this PR ready soon.

[davidhutchens]

Closing as completed.