Always use Java 15

[koppor]

Try to build JabRef with JDK15 (which was released 6 days ago - https://openjdk.java.net/projects/jdk/15/

[Siedlerchr]

If this works then #6829 can be deleted.
We need to test the windows installer and ensure jabref starts.
And rename the step please

[koppor]

I am not sure, what "works" means. In the PR #6829 no issue or PR or PR comment was linked describing the issue.

I think, it was a Windows issue?!

The build is located at https://builds.jabref.org/pull/6929/merge/.

[koppor]

Starts fine on Windows.

[Siedlerchr]

The standard setup action uses Zulu jdk that created problems because it was not signed and that created the problems hat jabref could not start.
Could be that they also switched to adoptopenjdk variant now again as they did with jdk14

[Siedlerchr]

Tested on windows and mac. Both start and mac is signed/notarized correctly

[tobiasdiez]

Could you please change jdk 14 to 15 everywhere. The local dev environment should be the same as the ci setup.

[Siedlerchr]

For development we should stick to jdk 14 because tooling/ide support for jdk 15 is (probably) not yet ready on all platforms.
The CI setup is primarily relevant for the jpackage stuff. That's why jdk 15 is used there.
In the end it's just the runtime that is shipped.

[koppor]

Using Liberca JDK 15 as of today does not work:

Task :compileJava
Skipped patching fastparse_2.12-1.0.0.jar into test
Skipped patching fastparse-utils_2.12-1.0.0.jar into test2
Skipped patching sourcecode_2.12-0.1.4.jar into test3
C:\git-repositories\jabref\jabref\src\main\java\module-info.java:67: error: module not found: jdk.internal.vm.compiler
    requires jdk.internal.vm.compiler;
                            ^
1 error

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

[Siedlerchr]

@koppor This looks exactly like the bug I encountered and reported to the AdoptOpenJDK team in the ea build and which got fixed in their variant. It's a problem with the building of client/server versions

adoptium/temurin-build#2047 (comment)