Support jpackage

[sormuras]

• https://openjdk.java.net/jeps/343
• https://openjdk.java.net/jeps/392 integrated in Java 16

bach/com.github.sormuras.bach/main/java/com/github/sormuras/bach/ProjectBuilder.java

Lines 348 to 350 in 745aaab

	public ToolCall computeMainJPackageCall() {
	return Command.builder("jpackage").build();
	}

[sormuras]

jpackage shipped with JDK 15-ea+33-1546 still warns about Using incubator modules: jdk.incubator.jpackage

[sormuras]

Integrated according to https://openjdk.java.net/jeps/392

But, module jdk.jpackage reads java.desktop ... 🥴

[sormuras]

Learnings from using jlink and jpackage:

• jpackage on Windows requires https://wixtoolset.org which in turn doesn't run on .NET 5, yet.
• jlink module java.net.http also requires jdk.crypto.ec for SSL hand-shakes (HTTPS)
• junit and other tools may required more system modules, like java.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.

[sormuras]

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

[sormuras]

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

[sormuras]

Next tests and results here: sormuras/bach-demo-javafx#1

Seems like keeping jpackage as dedidacted and platform-dependend job (including the build itself, due to "natives") is a better solution.