bach
bach copied to clipboard
Support jpackage
- https://openjdk.java.net/jeps/343
- https://openjdk.java.net/jeps/392 integrated in Java 16
https://github.com/sormuras/bach/blob/745aaab9e02b2e004016429b74a74abe0e0916c9/com.github.sormuras.bach/main/java/com/github/sormuras/bach/ProjectBuilder.java#L348-L350
jpackage
shipped with JDK 15-ea+33-1546
still warns about Using incubator modules: jdk.incubator.jpackage
Integrated according to https://openjdk.java.net/jeps/392
But, module jdk.jpackage
reads java.desktop
... 🥴
Learnings from using jlink
and jpackage
:
-
jpackage
on Windows requires https://wixtoolset.org which in turn doesn't run on .NET 5, yet. -
jlink
modulejava.net.http
also requiresjdk.crypto.ec
for SSL hand-shakes (HTTPS) -
junit
and other tools may required more system modules, likejava.logging
,java.management
, etc.
Especially the last finding will prevent that Bach will ship as a self-contained Java application. A full JDK with all system modules is mandatory.
When creating a custom runtime image via jlink
that includes module jdk.compiler
and its dependencies, the resulting javac
tool of that image doesn't support the --release
option.
The error message reads, using 16-ea+24
as the basis and --release 16
on the command:
release version 16 not supported
Usage: javac <options> <source files>
use --help for a list of possible options
Running javac --help
from within the custom image lacks all numbers:
[...]
--release <release>
Compile for the specified Java SE release. Supported releases:
-s <directory> Specify where to place generated source files
--source <release>, -source <release>
Provide source compatibility with the specified Java SE release.
Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
[...]
The help texts for options --source
and --target
do show all numbers.
Am I missing something? Perhaps an internal(?) module that contains the API definitions used by javac?
Tracked via https://bugs.openjdk.java.net/browse/JDK-8256343
Test-driven at https://github.com/sormuras/bach-lwjgl/blob/97ba2873c665a86fa2b3eadc128e6e00b3405c88/.github/workflows/build.yml#L34-L38 with generated packages attached as build artifacts at https://github.com/sormuras/bach-lwjgl/actions/runs/367789426
Next tests and results here: https://github.com/sormuras/bach-javafx/issues/1
Seems like keeping jpackage
as dedidacted and platform-dependend job (including the build itself, due to "natives") is a better solution.