Filling the Packager gap

[Johan Vos]

Hi,

As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager

With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.

Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)

- Johan

[Sverre Moe]

I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).

I was under the impression that the jpackager should also work to package
non-modular projects.

The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.

This produces the RPM for the modular project:
***@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication

Using the jpackager to package non modular project:
***@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar


ECHO-MODE: Running [rpmbuild, --version]

"Adding modules: [] to runtime image."

ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Exception in thread "main" jdk.packager.internal.PackagerException: Error:
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)

at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)

at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)


Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?

Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.

/Sverre

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

[Kevin Rushforth]

jpackager should work for non-modular applications as well as modular
ones. We've tested it for simple applications with or without FX. In the
latter case, the testing I've done has been done by first using jlink to
create a Java runtime with the needed JDK modules + the openjfx11
modules (using the jomds).

Andy might have additional comments.

-- Kevin

Post by Sverre Moe
I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).
I was under the impression that the jpackager should also work to package
non-modular projects.
The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar
ECHO-MODE: Running [rpmbuild, --version]
"Adding modules: [] to runtime image."
ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)
at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)
at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)
Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?
Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.
/Sverre

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

[Scott Palmer]

Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can’t automatically figure out module dependencies. The error below shows jlink is what is complaining.

Scott

jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds).
Andy might have additional comments.
-- Kevin

Post by Sverre Moe
I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).
I was under the impression that the jpackager should also work to package
non-modular projects.
The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar
ECHO-MODE: Running [rpmbuild, --version]
"Adding modules: [] to runtime image."
ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)
at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)
at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)
Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?
Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.
/Sverre

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

[Kevin Rushforth]

No, jlink won't link in a non-modular application. So the steps are:

1) Run jlink to create a Java runtime image, possibly stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above
Java runtime image.

-- Kevin

Post by Scott Palmer
Does jlink work for non-modular stuff? The last time I tried it complained to me too. I guess it gives up because it can’t automatically figure out module dependencies. The error below shows jlink is what is complaining.
Scott

jpackager should work for non-modular applications as well as modular ones. We've tested it for simple applications with or without FX. In the latter case, the testing I've done has been done by first using jlink to create a Java runtime with the needed JDK modules + the openjfx11 modules (using the jomds).
Andy might have additional comments.
-- Kevin

Post by Sverre Moe
I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).
I was under the impression that the jpackager should also work to package
non-modular projects.
The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar
ECHO-MODE: Running [rpmbuild, --version]
"Adding modules: [] to runtime image."
ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)
at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)
at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)
Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?
Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.
/Sverre

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

[Sverre Moe]

Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <

Post by Kevin Rushforth
1) Run jlink to create a Java runtime image, possibly stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above
Java runtime image.
-- Kevin

So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We cannot use
the javafx dependencies in the project?

jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found

The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs
--add-modules=java.logging --output image

Linking in with the JavaFX jmods from Gluon:
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs
--add-modules=java.logging --module-path /usr/java/javafx-jmods-11/
--add-modules=javafx.base --add-modules=javafx.controls
--add-modules=javafx.fxml --add-modules=javafx.graphics
--add-modules=javafx.web --add-modules=javafx.media
--add-modules=javafx.swing --output image

I managed to build our Java 8 project with Java 11, using the JavaFX
dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
--runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar

Running the application image from jpackager
First try:
I thought I had added all necessary modules to the runtime image, but I
needed one more, java.management.

Second try:
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
java.desktop) because module java.desktop does not export sun.swing to
module javafx.swing
at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.<clinit>(SwingNodeInteropO.java:71)

at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)

at
javafx.swing/javafx.embed.swing.SwingNode.<init>(SwingNode.java:271)
at no.company.application.fx.MySwingComponent.initNode(
MySwingComponent.java:155)

The module java.desktop should include the AWT/Swing.

At least I now have been able to create an native application using both
jlink and the new jpackager.

/Sverre

[Sverre Moe]

Without the reliance on javafx-swing I was able to create an image, package
and execute my test application.
Is the Swing problem a known bug in JavaFX 11?

The jlink runtime image I reckon now also contains the JavaFX modules?
Seems unnecessary when they already are dependencies.

/Sverre

Post by Sverre Moe
Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <

Post by Kevin Rushforth
1) Run jlink to create a Java runtime image, possibly stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above
Java runtime image.
-- Kevin

So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We cannot use
the javafx dependencies in the project?
jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found
The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output image
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --module-path
/usr/java/javafx-jmods-11/ --add-modules=javafx.base
--add-modules=javafx.controls --add-modules=javafx.fxml
--add-modules=javafx.graphics --add-modules=javafx.web
--add-modules=javafx.media --add-modules=javafx.swing --output image
I managed to build our Java 8 project with Java 11, using the JavaFX
dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
--runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar
Running the application image from jpackager
I thought I had added all necessary modules to the runtime image, but I
needed one more, java.management.
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
java.desktop) because module java.desktop does not export sun.swing to
module javafx.swing
at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.<clinit>(SwingNodeInteropO.java:71)
at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
at
javafx.swing/javafx.embed.swing.SwingNode.<init>(SwingNode.java:271)
at no.company.application.fx.MySwingComponent.initNode(
MySwingComponent.java:155)
The module java.desktop should include the AWT/Swing.
At least I now have been able to create an native application using both
jlink and the new jpackager.
/Sverre

[Kevin Rushforth]

I missed seeing the swing exception in your earlier message. Yes, the
Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is
documented in the release notes [2].

It will be fixed in openjfx12 just as soon as I push the fix for
JDK-8210092 [3] later today (the review was just finished earlier this
morning). This was one of the bugs waiting until the fix requiring JDK
11 for openjfx 12 was pushed.

As for your other question, yes, if you add the javafx.* modules to your
Java runtime image, then that runtime image contains the javafx.*
modules. If your application were modularized, then the Java runtime
image would contain your application, too.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8210759
[2]
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues
[3] https://bugs.openjdk.java.net/browse/JDK-8210092

Post by Sverre Moe
Without the reliance on javafx-swing I was able to create an image,
package and execute my test application.
Is the Swing problem a known bug in JavaFX 11?
The jlink runtime image I reckon now also contains the JavaFX modules?
Seems unnecessary when they already are dependencies.
/Sverre
Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe
Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth
1) Run jlink to create a Java runtime image, possibly stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above
Java runtime image.
-- Kevin
So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We
cannot use the javafx dependencies in the project?
jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found
The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output image
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --module-path
/usr/java/javafx-jmods-11/ --add-modules=javafx.base
--add-modules=javafx.controls --add-modules=javafx.fxml
--add-modules=javafx.graphics --add-modules=javafx.web
--add-modules=javafx.media --add-modules=javafx.swing --output image
I managed to build our Java 8 project with Java 11, using the
JavaFX dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output
outputDir --runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar
Running the application image from jpackager
I thought I had added all necessary modules to the runtime image,
but I needed one more, java.management.
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker"
java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in
module java.desktop) because module java.desktop does not export
sun.swing to module javafx.swing
       at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.<clinit>(SwingNodeInteropO.java:71)
       at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
       at
javafx.swing/javafx.embed.swing.SwingNode.<init>(SwingNode.java:271)
       at
no.company.application.fx.MySwingComponent.initNode(MySwingComponent.java:155)
The module java.desktop should include the AWT/Swing.
At least I now have been able to create an native application
using both jlink and the new jpackager.
/Sverre

[Sverre Moe]

Any chance of getting the fix for JDK-8210759 backported to JDK 11? I
remember reading the OpenJDK will be patched up to 2023 (while Oracle JDK
will be patched up to 2026).
We deliver software that our customers could be running for a decade or
more. The LTS is the version we will then target when we move away from
Java 8.

/Sverre

Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth <

Post by Kevin Rushforth
I missed seeing the swing exception in your earlier message. Yes, the
Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is
documented in the release notes [2].
It will be fixed in openjfx12 just as soon as I push the fix for
JDK-8210092 [3] later today (the review was just finished earlier this
morning). This was one of the bugs waiting until the fix requiring JDK 11
for openjfx 12 was pushed.
As for your other question, yes, if you add the javafx.* modules to your
Java runtime image, then that runtime image contains the javafx.* modules.
If your application were modularized, then the Java runtime image would
contain your application, too.
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8210759
[2]
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues
[3] https://bugs.openjdk.java.net/browse/JDK-8210092
Without the reliance on javafx-swing I was able to create an image,
package and execute my test application.
Is the Swing problem a known bug in JavaFX 11?
The jlink runtime image I reckon now also contains the JavaFX modules?
Seems unnecessary when they already are dependencies.
/Sverre

Post by Sverre Moe
Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <

Post by Kevin Rushforth
1) Run jlink to create a Java runtime image, possibly stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above
Java runtime image.
-- Kevin

So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We cannot use
the javafx dependencies in the project?
jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found
The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output image
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --module-path
/usr/java/javafx-jmods-11/ --add-modules=javafx.base
--add-modules=javafx.controls --add-modules=javafx.fxml
--add-modules=javafx.graphics --add-modules=javafx.web
--add-modules=javafx.media --add-modules=javafx.swing --output image
I managed to build our Java 8 project with Java 11, using the JavaFX
dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
--runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar
Running the application image from jpackager
I thought I had added all necessary modules to the runtime image, but I
needed one more, java.management.
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
java.desktop) because module java.desktop does not export sun.swing to
module javafx.swing
at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.<clinit>(SwingNodeInteropO.java:71)
at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
at
javafx.swing/javafx.embed.swing.SwingNode.<init>(SwingNode.java:271)
at no.company.application.fx.MySwingComponent.initNode(
MySwingComponent.java:155)
The module java.desktop should include the AWT/Swing.
At least I now have been able to create an native application using both
jlink and the new jpackager.
/Sverre

[Kevin Rushforth]

You mean openjfx11, not JDK 11, right? Backporting this fix would mean
an openjfx 11.x update release would stop building or running with JDK
10. Not something that would be done lightly, since it would break the
"FX N runs with JDK N-1" policy we have been discussing lately. There is
an easy workaround for that bug that needs to be done when running
"jlink" to create your image. It's documented in the release notes.

-- Kevin

Post by Sverre Moe
Any chance of getting the fix for JDK-8210759 backported to JDK 11? I
remember reading the OpenJDK will be patched up to 2023 (while Oracle
JDK will be patched up to 2026).
We deliver software that our customers could be running for a decade
or more. The LTS is the version we will then target when we move away
from Java 8.
/Sverre
Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth
I missed seeing the swing exception in your earlier message. Yes,
the Swing issue is a known problem in openjfx11, JDK-8210759 [1],
and is documented in the release notes [2].
It will be fixed in openjfx12 just as soon as I push the fix for
JDK-8210092 [3] later today (the review was just finished earlier
this morning). This was one of the bugs waiting until the fix
requiring JDK 11 for openjfx 12 was pushed.
As for your other question, yes, if you add the javafx.* modules
to your Java runtime image, then that runtime image contains the
javafx.* modules. If your application were modularized, then the
Java runtime image would contain your application, too.
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8210759
[2]
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues
[3] https://bugs.openjdk.java.net/browse/JDK-8210092

Post by Sverre Moe
Without the reliance on javafx-swing I was able to create an
image, package and execute my test application.
Is the Swing problem a known bug in JavaFX 11?
The jlink runtime image I reckon now also contains the JavaFX
modules? Seems unnecessary when they already are dependencies.
/Sverre
Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe
Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth
No, jlink won't link in a non-modular application. So the
1) Run jlink to create a Java runtime image, possibly
stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application
with the above
Java runtime image.
-- Kevin
So we have to create the image with the jlink first before we
use jpackager, and we have to link in with the javafx
modules. We cannot use the javafx dependencies in the project?
jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found
The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output image
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging
--module-path /usr/java/javafx-jmods-11/
--add-modules=javafx.base --add-modules=javafx.controls
--add-modules=javafx.fxml --add-modules=javafx.graphics
--add-modules=javafx.web --add-modules=javafx.media
--add-modules=javafx.swing --output image
I managed to build our Java 8 project with Java 11, using the
JavaFX dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output
outputDir --runtime-image image/ --verbose --echo-mode
--main-jar application-1.0.0-SNAPSHOT.jar
Running the application image from jpackager
I thought I had added all necessary modules to the runtime
image, but I needed one more, java.management.
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker"
java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in
module javafx.swing) cannot access class
sun.swing.JLightweightFrame (in module java.desktop) because
module java.desktop does not export sun.swing to module
javafx.swing
       at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.<clinit>(SwingNodeInteropO.java:71)
       at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
       at
javafx.swing/javafx.embed.swing.SwingNode.<init>(SwingNode.java:271)
       at
no.company.application.fx.MySwingComponent.initNode(MySwingComponent.java:155)
The module java.desktop should include the AWT/Swing.
At least I now have been able to create an native application
using both jlink and the new jpackager.
/Sverre

[Sverre Moe]

Den tor. 27. sep. 2018 kl. 18:50 skrev Kevin Rushforth <

You mean openjfx11, not JDK 11, right? Backporting this fix would mean an
openjfx 11.x update release would stop building or running with JDK 10. Not
something that would be done lightly, since it would break the "FX N runs
with JDK N-1" policy we have been discussing lately. There is an easy
workaround for that bug that needs to be done when running "jlink" to
create your image. It's documented in the release notes.
-- Kevin

Yes, I meant OpenJFX 11. I will take a look at the release notes to find
the workaround.

/Sverre

[Ty Young]

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

The JDK source fails to compile due to a duplicate qualified export.
Removing the export from
openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java
fixes it.


By the way, how does one use this with jLink generated by Netbeans? I
used the jLink build as the input and it just dumped it into the "app"
folder when making the image which doesn't work.

[Johan Vos]

Hi Ty,

Apart om jdk.jlink, who else is exporting jdk.tools.jlink.internal.packager
?
If that is the case, there must be something wrong.
The 12-sandbox version also exports that package:
http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java

- Johan

Post by Johan Vos

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap.

Work

Post by Johan Vos
for the new Java Packager (12?) is being done in the OpenJDK sandbox

repo.

Post by Johan Vos
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the

packager

Post by Johan Vos
(wrapper/exe + module including native library). They can be downloaded

and

Post by Johan Vos
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the

JDK,

Post by Johan Vos
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

The JDK source fails to compile due to a duplicate qualified export.
Removing the export from
openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java
fixes it.
By the way, how does one use this with jLink generated by Netbeans? I
used the jLink build as the input and it just dumped it into the "app"
folder when making the image which doesn't work.

[Ty Young]

Post by Johan Vos
Hi Ty,
Apart om jdk.jlink, who else is
exporting jdk.tools.jlink.internal.packager ?
If that is the case, there must be something wrong.
http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java
- Johan

JavaFX itself is:


rt/apps/performance/JavaFX/src/jdk.jlink/classes(It's just an app)

module-info.java.extra from /rt/dependencies/jdk.jlink

module-info.java.extra from /rt/build/modular-sdk/modules_src/jdk.jlink


I don't know what the .extra is all about. I found those by searching
for all the module-info files from in JavaFX and seeing if there was any
matches to jdk.tools.jlink.internal.packager.

Post by Johan Vos

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the

packager-gap. Work

Post by Johan Vos
for the new Java Packager (12?) is being done in the OpenJDK

sandbox repo.

Post by Johan Vos
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain

the packager

Post by Johan Vos
(wrapper/exe + module including native library). They can be

downloaded and

Post by Johan Vos
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory

as the JDK,

Post by Johan Vos
as the packager wrapper expect to find the java binary at the

same level.

Post by Johan Vos
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that

works

Post by Johan Vos
fine), and they do what we expect them to do, but there are no

guarantees

Post by Johan Vos
of course so at least for now I recommend using them in

development only

Post by Johan Vos
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this

backport)

Post by Johan Vos
- Johan

The JDK source fails to compile due to a duplicate qualified export.
Removing the export from
openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java
fixes it.
By the way, how does one use this with jLink generated by Netbeans? I
used the jLink build as the input and it just dumped it into the "app"
folder when making the image which doesn't work.

[Sverre Moe]

I am having some problems accessing the jpackager from symlinks, seems it
cannot find the jdk.packager.jar

/usr/bin/jpackager -> /etc/alternatives/jpackager
/etc/alternatives/jpackager -> /usr/java/jpackager/jpackager

:/ # jpackager --help
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.packager not found

Though accessing the jpackager directly works fine:
/usr/java/jpackager/jpackager

Any suggestion what the problem might be and how to remedy this?

/Sverre

[Dean Wookey]

Hi,

I got jpackager working with OpenJDK11.0.1 after a bit of trial and error.
I'm now able to create a windows image like I had before with javapackager.
I thought I'd share some of the issues I've had in case it helps anyone out.

The first one was that you need to copy jdk.packager.jar not only into the
bin directory, but also into the jmods directory. If you don't, you get a
cryptic nullpointer exception from the jpackager in verbose mode. I'm sure
it's expecting a jdk.packager.jmod there that contains the list of files
it's looking for.

The second is that --jvm-args only seems to respect the first instance of
an argument. For example, you can have multiple--add-exports arguments. All
of them will get stored in the cfg file in the image's app directory, but
only the first instance will get passed to the jvm by the native executable.

Otherwise, works well, at least for our needs. Thank you.

Dean

Post by Johan Vos
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan

[Sverre Moe]

This post might be inappropriate. Click to display it.