3dcitydb / citydb-tool

3D City Database 5.0 CLI to import/export city model data and to run database operations
Apache License 2.0
9 stars 2 forks source link

Java 11 EOL #2

Closed BWibo closed 8 months ago

BWibo commented 9 months ago

Depending on the platform, Java 11 has already or will reach EOL soon, e.g. Oracle JDK, EOL Sep 2023, OpenJDK, EOL Oct 2024. I suggest we move to the next LTS versions, Java 17 or Java 21.

clausnagel commented 9 months ago

Firstly, and as far as I understand, security updates will be available for Java 11 until 2032, right? So, there is no real need to change the Java version now.

Secondly, do you want to use Java 17 or 21 for the Docker image running the command-line tool or as basis for the source code? The difference is that we can easily use any Java version >= 11 to run the compiled citydb-tool on the command line. But this repository also provides a Java API and library which can be used by others to build their own software with 3DCityDB support. If we use Java 17 or 21 as basis for our source code, this will also be a mandatory dependency for users of our API. On the other hand, having a first stable release based on Java 11 and changing the Java version later will mean a breaking change for users. So maybe we should switch to a newer Java version before the first stable release?

@yaozhihang, what do you think? Java 17 and 21 introduce nice language features such as records, sealed classes and virtual threads that might be interesting to use. Should we switch now?

yaozhihang commented 9 months ago

I think we could switch java 17 or 21. It looks more strict to the java environment requirements. But there are also nice solutions e.g. we can build our citydb-tool together with a light-weight java runtime.

BWibo commented 9 months ago

There is no specific reason for me to use Java 17 or 21. I just saw that some distributors are starting to EOL Java 11, so I figured it's best to move to a newer version now and avoid making the change in the near future. As you do the dev work, you should decide this.

BWibo commented 9 months ago

One more thing I came accross. I tried building the tool with a Java 17 base image, but that fail. README.md currently says Java 11 or higher is requried. I believe this is related to this line: https://github.com/3dcitydb/citydb-tool/blob/48e32cad98916d24cf4738135a3b09e377bf8804/build.gradle#L24

clausnagel commented 9 months ago

No issue on my local machine. Can build with Java 17 without issues. Can you post the error message?

BWibo commented 9 months ago

Der Fehler tritt auf, wenn ich mit dem JDK 17 als baseimage bauen möchte:

docker build --progress=plain \
  --build-arg RUNTIME_IMAGE_TAG=17-jdk \
  --build-arg BUILDER_IMAGE_TAG=17-jdk -t test .
#8 [builder 4/4] RUN chmod u+x ./gradlew && ./gradlew installDist
#8 0.324 Downloading https://services.gradle.org/distributions/gradle-8.4-bin.zip
#8 1.254 ............10%............20%.............30%............40%.............50%............60%.............70%............80%.............90%............100%
#8 3.409
#8 3.409 Welcome to Gradle 8.4!
#8 3.409
#8 3.409 Here are the highlights of this release:
#8 3.409  - Compiling and testing with Java 21
#8 3.409  - Faster Java compilation on Windows
#8 3.410  - Role focused dependency configurations creation
#8 3.410
#8 3.410 For more details see https://docs.gradle.org/8.4/release-notes.html
#8 3.410
#8 3.508 Starting a Gradle Daemon (subsequent builds will be faster)
#8 15.11
#8 15.11 FAILURE: Build failed with an exception.
#8 15.11
#8 15.11 * What went wrong:
#8 15.11 Could not determine the dependencies of task ':citydb-cli:installDist'.
#8 15.11 > Could not resolve all dependencies for configuration ':citydb-cli:runtimeClasspath'.
#8 15.11    > Failed to calculate the value of task ':citydb-cli:compileJava' property 'javaCompiler'.
#8 15.21       > No matching toolchains found for requested specification: {languageVersion=11, vendor=any, implementation=vendor-specific} for LINUX on x86_64.
#8 15.21          > No locally installed toolchains match and toolchain download repositories have not been configured.
#8 15.21
#8 15.21 * Try:
#8 15.21 > Learn more about toolchain auto-detection at https://docs.gradle.org/8.4/userguide/toolchains.html#sec:auto_detection.
#8 15.21 > Learn more about toolchain repositories at https://docs.gradle.org/8.4/userguide/toolchains.html#sub:download_repositories.
#8 15.21 > Run with --stacktrace option to get the stack trace.
#8 15.21 > Run with --info or --debug option to get more log output.
#8 15.21 > Run with --scan to get full insights.
#8 15.21 > Get more help at https://help.gradle.org.
#8 15.21
#8 15.21 BUILD FAILED in 14s
#8 ERROR: process "/bin/sh -c chmod u+x ./gradlew && ./gradlew installDist" did not complete successfully: exit code: 1

Anscheinend fehlt die Toolchain, bzw. das Repo dafür.

clausnagel commented 9 months ago

Right. Seems that there has been a change in Gradle 8. Before 8, Gradle automatically downloaded a Java version matching the configured toolchain in case the locally installed version didn't match. Since 8, a download repository must be configured which we haven't done so far.

Let's first decide whether we move the source code to Java 17. Java 21 is not supported by Gradle at the moment, so I would skip this option.

yaozhihang commented 9 months ago

I would first keep Java 11 at the moment. As soon as the Gradle supports java 21, we should test if we can get significant performance benefit from the Java Virtual Threads. If yes, Switching to java 21 is nice.

yaozhihang commented 9 months ago

Switching to java 17 now is also not bad.

clausnagel commented 8 months ago

moved to Java 17 with cca0f64821887fc916940468ef61cfcb4d4b1408