2281: Upgrade to JRE 25

[andrew8er]

Short Description

Upgrades the required build JDK to 25.

Proposed Changes

• Upgrade the required backend JDK to 25. The sourceCompatibility and targetCompatibility are still set to 24, since Kotlin does not support 25 at the moment. This will be resolved soon after updating to Kotlin 2.3.0, which is in beta now:
  • https://youtrack.jetbrains.com/issue/KT-81077/Add-JVM-target-bytecode-version-25
  • https://kotlinlang.org/docs/whatsnew-eap.html#kotlin-jvm-support-for-java-25
• Removed the entitlementcard-jdk IntelliJ option. Let users just declare a "project SDK".
• Update the CircleCI images for building/checking the backend.
• Add a install_temurin command and add it to pack_backend job.
• A few smaller improvements to the Gradle file:
  • Do not use maven group name for deducing package root: the Maven group name and the package root are two totally unrelated concepts and should not be conflated.
  • Extract CI config into object: put all environment variables set by the CI pipeline into an object for better clarity in the Gradle file. Also remove the usage of SENTRY_AUTH_TOKEN, use SENTRY_BACKEND_AUTH_TOKEN directly.
• Remove this block from the Gradle file, which caused the "main" jar to not be included in the final distribution artifact:

  tasks.withType<Zip>().configureEach {
      enabled = false
  }
  

• Update the setup docs.

Open questions

• Are there any downside with removing the entitlementcard-jdk variable? I think it just posed a layer of indirection.

  No

• How can I test the pack_backend job?

  Tested: https://app.circleci.com/pipelines/github/digitalfabrik/entitlementcard/10162/workflows/516ba00f-a25c-4a8b-8e34-a185301e7d67

Side Effects

None

Testing

• Run backend
• Run tests

Resolved Issues

Fixes: #2281

[f1sh1918]

1. I think this variable should automatically resolve the correct jdk for this project, no? Actually for me its not working for couple of time so i don't mind removing it. I even never touched this configuration so maybe @michael-markl has some input

• You can make a temporary commit and comment out the delivery steps(delivery_beta_all.yml):

  - deliver_server:
      production: false
      context:
        - credentials-ehrenamtskarte
      requires:
        - pack_administration
        - pack_backend
        - pack_martin
        - pack_meta

  - notify_release:
      production_delivery: false
      context:
        - deliverino
      requires:
        - deliver_android
        - deliver_ios
        - deliver_server

• Then update the config.yml (package.json script)
• trigger delivery_beta_all via circle ci GUI
  If you think it may make sense to create a "test" workflow you could also add one
  So far we didn't have to test that frequently.

[f1sh1918]

I tested your draft and it works well so far.
I think you could also enable virtual threads in this issue. I think its not worth creating a separate pr for that

spring.threads.virtual.enabled=true

I get some warnings during backend start but i guess you also realized this

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::invokeCleaner has been called by nonapi.io.github.classgraph.utils.FileUtils (file:/Users/afischer/.gradle/caches/modules-2/files-2.1/io.github.classgraph/classgraph/4.8.174/d86b16ab77abd87118b51e6a2c61e2d44ce6deaa/classgraph-4.8.174.jar)
WARNING: Please consider reporting this to the maintainers of class nonapi.io.github.classgraph.utils.FileUtils
WARNING: sun.misc.Unsafe::invokeCleaner will be removed in a future release

[michael-markl]

I think this variable should automatically resolve the correct jdk for this project, no? Actually for me its not working for couple of time so i don't mind removing it. I even never touched this configuration so maybe @michael-markl has some input

I am not sure which variable you mean. I don't have immediate feedback here. As long as everything works, these changes seem fine to me (without having checked them in depth :D )

[andrew8er]

@f1sh1918

I think this variable should automatically resolve the correct jdk for this project, no? Actually for me its not working for couple of time so i don't mind removing it. I even never touched this configuration so maybe @michael-markl has some input

For me it mostly didn't work, though more often in the last few days, strangely enough. But yes, with this configuration, Gradle should chose the correct version automatically.

You can make a temporary commit and comment out the delivery steps(delivery_beta_all.yml):

Thanks, I'll try it.

I tested your draft and it works well so far.
I think you could also enable virtual threads in this issue. I think its not worth creating a separate pr for that

I would prefer to do this in a separate PR. The general advice here is to test this thoroughly.

I get some warnings during backend start but i guess you also realized this

I saw those, these are from one of our dependencies. We could suppress them, but I'd rather have them as a reminder to update our dependencies regularly.

@michael-markl

I am not sure which variable you mean. I don't have immediate feedback here. As long as everything works, these changes seem fine to me (without having checked them in depth :D )

The IntelliJ config option removed here: https://github.com/digitalfabrik/entitlementcard/pull/2657/files#diff-952b752681ded498853ce6363aa309aac9e6bd15fe12a907be0b8d2142d1fa21L8

[f1sh1918]

I guess we also have to update the jdk on our Servers before doing a release

[andrew8er]

The JDK update is tracked here: https://tasks.tuerantuer.org/projects/infra/work_packages/4793/activity

[f1sh1918]

https://tasks.tuerantuer.org/projects/infra/work_packages/4793/activity

🙈 sure... looks like it's monday
Okay works fine

[andrew8er]

So after literally hours of figuring out, why the "main" jar was not packaged into the backend.tar artifact, I found out that this was the cause (in build.gradle.kts):

tasks.withType<Zip>().configureEach {
    enabled = false
}

@seluianova
What was this actually supposed to do? I guess it should inhibit the building of the zip file when building the assemble or assembleDist task? For whatever reason, it caused a seemingly totally unrelated side effect. I removed it, building the distTar task is enough.

[f1sh1918]

So after literally hours of figuring out, why the "main" jar was not packaged into the backend.tar artifact, I found out that this was the cause (in build.gradle.kts):

tasks.withType<Zip>().configureEach {
    enabled = false
}

@seluianova
What was this actually supposed to do? I guess it should inhibit the building of the zip file when building the assemble or assembleDist task? For whatever reason, it caused a seemingly totally unrelated side effect. I removed it, building the distTar task is enough.

I don't get why there are such side effects but okay.
I suggested adding this line because we don't need the zip file but the only tar?

I think with Java 17 there were no issues at all?

Didn't know that there is a particular job in gradle

[f1sh1918]

i get only issue running distTar probably typo
Thx for improving docs

[andrew8er]

@f1sh1918

I think with Java 17 there were no issues at all?

I tested this with JDK 17, 21 and 25 as the Gradle platform. All had the same effect, with

tasks.withType<Zip>().configureEach {
    enabled = false
}

the main jar in the dist tar is missing. So I'm pretty sure this did not ever work on a real deployment.

[f1sh1918]

Maybe it would be good to know which issues exactly you are talking about. @seluianova deployed it with java 17 on staging and we couldn't figure out issues directly after deployment

[andrew8er]

Steps to reproduce:

• Build the backend with a clean env (delete /backend/build): SENTRY_AUTH_TOKEN=<sentry_token> ./gradlew assemble -Denv=prod
• Unpack the dist tar file: /backend/build/distributions/backend.tar
• Try to run resulting bin/backend. An error is produced:

Error: Could not find or load main class app.ehrenamtskarte.backend.EntryPointKt
Caused by: java.lang.ClassNotFoundException: app.ehrenamtskarte.backend.EntryPointKt

This is because the file lib/backend-0.0.1-SNAPSHOT-plain.jar is missing, which contains our code.

• Remove the offending block
• Delete /backend/build again
• Retry

[seluianova]

@seluianova deployed it with java 17 on staging and we couldn't figure out issues directly after deployment

actually I applied this suggestion after the deployment, so yes, this issue could happen.
good to find this now, thanks @andrew8er

[seluianova]

lgtm!

[andrew8er]

I'll wait with merging this PR until JDK 25 is available on our server: https://tasks.tuerantuer.org/projects/infra/work_packages/4793/activity

[f1sh1918]

@andrew8er jdk25 is running on staging server. afaics it runs stable. I think we can merge this pr

[andrew8er]

It needs another review.