How to copy jre executables to runtime bundled jre?

[gabrielpaim]

Hi there,

I want to package a self contained java 8 application for windows/osx, but with a particular request: the executables from JRE (e.g., java.exe) should be bundled together with the runtime folder.

I don't know if this could be done with this tool, as the JavaPackager utility (and also the deploy task of the AntBuilder) strips by default the executable from the bundled jre. The JavaPackager from jdk10 has an opened parameter for this - called "strip-native-commands", but I think jdk10 packager doesn't allow one to package a java8 application. At least it's clearly stated that one should use jdk8 packager to package java 8 or 7 apps.

Maybe this could not be done with this plugin, as it seems it's more a oracle's issue, but maybe some of you have already experienced such situation. @FibreFoX maybe you too, with your several hacks workarounds, have any idea about that :)

Thank you!

[FibreFoX]

Hi there,

yes, this sounds like another hack-around of the javapackager-core. What installer are you intending to use? Or are you just using the "windows.app"/"mac.app"-bundlers?

[gabrielpaim]

I'm planning to use the default installers for win/mac, the .exe and .dmg. But I don't have any special requirement here, if there is another solution (msi, for instance), it would be no problem for me.

I was thinking about this strategy:

• packaging the app using the "native image" option (to create the folder structure)
• manually copying the jre executables depending on the detected OS
• "packaging" the resulting folder to the installer (using innoSetup for windows).

What do you think?

Thank you.

[FibreFoX]

I'll check the implementations of the bundlers :) I think there might be a chance to have this being possible, will report back.

[FibreFoX]

It seems that I already have implemented a workaround for this: #38

The problem:
the JDK-provided bundler are a bit stupid, each one creates their own stuff without reusing the previous created stuff. Calling jfxNative on windows (when having both InnoSetup and WiX installed) calles the windows.app bundler first, which copies the stripped JRE and create the {appName}-folder inside build/jfx/native/. After that being created, the win,exe-bundler is called, and here begins the trouble: it re-creates the whole stuff created by the windows.app-bundler (it even calls it directly). The biggest pain-point is, that this bundle (windows.app called by win.exe) is not reachable, as the workspace-folder is below TEMP and is cleaned recursively before it's getting copied to. After that bundle is done, the main installer-creation bundler-stuff happens.

The workaround:
The good thing about the re-creation of the "temporary"-folder is, that on windows I'm able to sneak my self-created folder into the internal hashmap, which contains all the sensitive moving parts of each bundler-run. You can see this here: https://github.com/FibreFoX/javafx-gradle-plugin/blob/newyear2018release/src/main/java/de/dynamicfiles/projects/gradle/plugins/javafx/tasks/workers/JfxNativeWorker.java#L460

The ugly:
It only works for windows and linux ... as the developers of the javapackager bundlers were probably very sleepy while creating their bundle-creation-classes, ALL BUNDLERS ARE NOT EQUAL. They are re-implemented in their own custom way, making it impossible to rely on anything learned from a different bundler. ANY MAC-BUNDLERS are not able to use this workaround, sadly.

The "needs more work" workaround:
implementing your own bundler, adding it to the classpath and referencing it via bundler-propery of this plugin.

This does not work on JDK9+ as the smart-asses tried to be intelligent when inventing JPMS, hiding all resources from being able to "see", making it impossible to implement it in a simple way.

To all Oracle-developers and the bundler-creators: this is no personal attack, just my frustration about your very bad and unreasonable design-choices. For that reason I tried to create my alternative re-implementation of all stuff: https://github.com/FibreFoX/distribution-bundle-plugin-for-maven .... which I currently don't have the time, but am trying to get this being published before JDK11 hits the web (because the future of JavaFX will be ... different after that release as JavaFX is not bundled anymore).

[DJViking]

Danny, maybe you should voice your concern regarding the draft proposal for new packager:
"Draft JEP for new Packaging Tool (replacement for javapackager)"
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021941.html

This is intended as a JDK-scope replacement for the existing
javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK
releases), and was delivered as part of the JavaFX build. The
javapackager tool has been removed from Oracle JDK 11 along with the
removal of JavaFX.

https://bugs.openjdk.java.net/browse/JDK-8200758

[FibreFoX]

@DJViking thanks for pointing to that JEP :)