Towards Java 14 and Modularity

[skaldarnar]

Working towards using Java 14 and jpackage to build platform-specific versions of that launcher that can be installed properly. This comes with a bunch of related changes and requirements (such as downloading the runtime by the launcher itself instead of bundling it with each release, and many more).

This issue aims to track progress on the matter.

• chore: Update to Gradle 6.3 and Java 14 #561 first attempt to upgrade, likely to be split into smaller parts
• chore: Remove usage of JNA to determine Windows path #564 remove JNA for minimal Windows-specific native platform code
• test: use spf4j-slf4j-test to unit test logging #562 reworks our test dependencies which likely has an influence on what modules we're dealing with (by @keturn)
• badass-jlink-plugin brings support for jlink and jpackage to Gradle
• gradle-modules-plugin ... for what exactly? I guess something with modules 🙄
• Running launcher without any JAVA installed. #490 first attempt to upgrade to modularized launcher by @DarkWeird
• https://github.com/JabRef/jabref as reference for an application that already did the switch...

Next action items:

• - Use https://github.com/github-api/github-api instead of jcabi github API as javax.json and gson don't work together well. Having both as dependencies let to StackOverflowError when running the Gradle jlink task (chore: Replace jcabi Github client by github-api #567)
• - Remove JRE downloading and bundling and handle the JRE by the launcher at runtime (this obviously only makes sense if we can start the launcher on its own)
• - We're using a pretty outdated (like, 5 years or so) library to render our markdown files within the launcher (txtmark) - maybe it's time to upgrade this as well... Possible replacements include atlassian/commonmark-java or vsch/flexmark-java

[keturn]

Does Java 14 require we jlink, or may we start by bumping up some versions and distributing the java 14 JRE? (I think I did read somewhere that Oracle wasn't distributing JREs anymore, they said if you want to distribute a runtime smaller than the JDK you can do a jlink or whatever.)

Since #562 is only test dependencies, I expect it to interact with this less than if it were application code. 🤞

Gradle 6.4 (currently at release candidate 4) will have its own support for modular builds. I'm making assumptions here but I'd expect that to replace the org.javamodularity.gradle-modules-plugin. I don't know their timeline but rc4 sounds close to release, doesn't it? I'd be tempted to build on that instead of starting on one and switching.

[keturn]

There is one thing in #562 that might be relevant: It pulls in a component metadata plugin. I don't know if that helps with module conflicts at all, but it does help expose it when incompatible packages are on the classpath.

[skaldarnar]

The game does not run with Java 14 afaik. I think we can prepare a few things (like cleaning up our dependencies or upgrading Gradle) but at some point we'll do hard cut.
I think jlink is availabe before 14, so we could probably move to building a minimal runtime for the launcher with jlink and downloading a separate JRE for the game (at launcher runtime). Final step would be to use jpackage to get nice installers...

Waiting for Gradle 6.4 - depends on when it is released. If it is ready we should go for it, but I'll continue to use the modularity plugin for now in hope to easily get rid of it. Reason is that I don't want to block this project unnecessarily...