Update to JDK22 for building

[koppor]

JDK22 is generally available (GA). Since we use the Gradle Toolchain feature, we can use it for building.

I did NOT update the JDK for gradle itself, gradle itself does not support JDK22 yet (gradle/gradle#26162).

• Update documentation that JDK 22 should be used in IntelliJ

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

Do we use it for deployment/building? Because jdk21 is long term and 22 might not yet be available for all unix distributions pakaged etc, This will create issues with people building jabref themselves

[koppor]

Updated EA build to use 23 only:

[github-actions]

The build for this PR is no longer available. Please visit https://builds.jabref.org/main/ for the latest build.

[koppor]

Do we use it for deployment/building?

With this configuration: yes.

We do not yet use JDK 22 features. But we are ready now. The variable https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api/-java-version/-v-e-r-s-i-o-n_22/index.html exist.

New on JDK 22: https://www.infoworld.com/article/3708329/jdk-22-the-new-features-in-java-22.html

Maybe the "structured concurrency" is cool for our file indexer:

With structured concurrency, from Project Loom, concurrent programming is simplified through an API that treats groups of related tasks running in different threads as a single unit of work,

And even cool String templates: https://openjdk.org/jeps/459

Oh, we finally do have _ to ignore variables - https://openjdk.org/jeps/456

---

Because jdk21 is long term and 22 might not yet be available for all unix distributions pakaged etc, This will create issues with people building jabref themselves

At least debian has JDK22 (https://packages.debian.org/sid/openjdk-22-jdk). 😅

[Siedlerchr]

Rather arch and other distributions...https://archlinux.org/packages/?sort=&q=openjdk&maintainer=&flagged=

[koppor]

I think, we have to wait until JDK22 appears somehow in the Gradle Java compatibility matrix

---

This motivates me to try out bld or Bach :)

[koppor]

Gradle 8.7 will support compiling using JDK22: gradle/gradle#26245

[koppor]

JDK22 compilation is enabled in #11059 (for the EA builds only)

[koppor]

#11430 might need unnamed variables -- thus reopening the PR. Should happen for JabRef 6.0

[koppor]

Oh, we also need to update the workflows themselves to enable jpackage. Otherwise:

Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 66.0

[koppor]

Seeing that Java 25 is going to be an LTS again (see https://www.oracle.com/de/java/technologies/java-se-support-roadmap.html), we could wait 1 year for a Java update. Seeing the effort for updating (also at the local developer's machine), unless we really require a new feature, we should stick with LTS.