Upgrade to Gradle 9 and migrate to Kotlin DSL

[lesserwhirls]

Description of Changes

Upgrade to Gradle 9 and migrate from the groovy DSL to the Kotlin DSL.

PR Checklist

• Link to any issues that the PR addresses
• Add labels
• Open as a draft PR
  until ready for review
• Make sure GitHub tests pass
• Mark PR as "Ready for Review"

[lesserwhirls]

With the move to Gradle 9, Java 17 is now required to run the build (the build will produce java 8 bytecode, so no change in the minimum version supported, and java 8 will be used by the build to run the tests).

I tried to keep the build commands the same during this transition (e.g. ./gradlew buildNetcdfAll, jar available under build/distributions/). The content of the uber-jars is now controlled in uber-jars/build.gradle.kts.

There is no longer a testAll task - it's all handled by test. The test task requires that gradle can find a Java 8 install. It does an ok job out-of-the-box figuring out if there is one, but if not, check out the Gradle toolchains docs for details on how to help gradle find your install. The tests can be run with all other LTS versions of Java using the testX tasks (where X is a LTS version number, e.g. test25).

New build system just in time for Halloween...spooky!

[rschmunk]

Ooooph, some changes. A couple notes…

I see some errors when doing a ./gradlew buildNetcdfAll, but they aren't fatal. At least one had to do with applying spotless, which obviously isn't 'necessary'.

I had to dig around for a few minutes to figure out how to modify the config settings so as to include some extra items in my "x" build of netcdfAll., as there is no longer a gradle/fatjars config file. Search eventually revealed the appropriate updated config was located in the uber-jars directory, which makes far too much sense. Obviously, I didn't read your commit notes above.

Belatedly discovered the Java version requirement for building NJ via the new procedure after I deleted Java 25 from this particular Mac. Which okay, I can still update my copy of NJ but not so often. (You should see my archive of Java for Mac installers.) I still prefer to use an actual Java 11 to build my Java 11 app, as there were stories back in ye olden days that using a newer to target an older might trigger arcane bugs.

[lesserwhirls]

Greetings @rschmunk! Next time I make build changes I'll be sure to tag you as a heads-up. I still need to update the project wiki to account for these changes, but that document is a bit out of date as-is.

I could change the build to use a Java 8 toolchain for compiling the code, like I do with using Java 8 for running the tests. It would still require a Java 17+ install to run the build itself, but it would use JDK 8 for all of the compile steps. I decided to go with using the release flag for producing Java 8 byte code, as it's widely recommended now and more simple for someone just looking to build the project. However, by default the test run using JDK 8 (which can take a little configuration to ensure the build knows where a JDK 8 can be found). My hope is that will catch any of those arcane bugs of which you speak, as we've ran into that before in the 2010s (I think we were using 7 to target 6). Since the JDK moved away from the source and target flags to the release flag (I believe that happened in 9), life in this area has significantly improved. I too am still a bit leery, but perhaps foolishly optimistic.