Description of problem: The code for javapackager (1) doesn't copy symlinks in the runtime of the generated bundle. tzdb.dat in java-1.8.0-openjdk is a symlink. Due to the use of caches in java (2), in (presumably) most cases the file is *not* seen as a symlink (I don't understand why) and is copied. In some cases (in my case, when I add a 30+ megabytes binary in the jar of my application. It is very reproducible on my machine), it is seen as a symlink and not copied. When tzdb.dat is not copied, the generated bundle doesn't start: # a typical linux-app Bundle with javapackager $ ls MyApp app MyApp libpackager.so runtime $ MyApp/MyApp MyApp Error invoking method. MyApp Failed to launch JVM (1) see http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/9f49e3b6147f/modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java JreUtils.extractJreAsRelativeFileSet without a third boolean parameter defaults acceptSymlinks=false in http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/9f49e3b6147f/modules/fxpackager/src/main/java/com/oracle/tools/packager/JreUtils.java (2) see -Dsun.io.useCanonCaches=false or -Dsun.io.useCanonPrefixCache=false Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. build a javafx application with -Dsun.io.useCanonCaches=false (for example, use maven maven-javafx-plugin and MAVEN_OPTS="-Dsun.io.useCanonCaches=false" 2. run the generated app for example, clone https://github.com/cleitonferreira/helloworld-javafx-maven-plugin and run $ mvn clean package jfx:jar jfx:native -Dproject.organization.name=foo -Djfx.bundler=linux.app #should work and open a window $ target/jfx/native/helloworld-javafx-maven-plugin/helloworld-javafx-maven-plugin #now retry without the canoncaches: MAVEN_OPTS="-Dsun.io.useCanonCaches=false" mvn clean package jfx:jar jfx:native -Dproject.organization.name=foo -Djfx.bundler=linux.app # fails $ target/jfx/native/helloworld-javafx-maven-plugin/helloworld-javafx-maven-plugin helloworld-javafx-maven-plugin Class br/com/nuvemapp/helloworld/MainApp not found. helloworld-javafx-maven-plugin Failed to launch JVM Actual results: $ MyApp/MyApp MyApp Error invoking method. MyApp Failed to launch JVM Expected results: $ MyApp/MyApp [.. app starts normally..] Additional info:
I have tested the step to reproduce the error. I modified the LinuxAppBundler to call the method JreUtils.extractJreAsRelativeFileSet with 3 arguments and it's seems to work now in both cases. I have only executed on fedora the result. I will test also on another distro. It seems to be a bug in openjfx?
I have tested on Ubuntu 18.04 LTS the output mentioned above, but I have this error: $ target/jfx/native/helloworld-javafx-maven-plugin/helloworld-javafx-maven-plugin Failed to find library. /home/deamn/git/helloworld-javafx-maven-plugin/target/jfx/native/helloworld-javafx-maven-plugin/runtime/lib/amd64/server/libjvm.so helloworld-javafx-maven-plugin Failed to locate JNI_CreateJavaVM helloworld-javafx-maven-plugin Failed to launch JVM When I replace the libjvm.so from fedora with that of Oracle, I have this error: $ target/jfx/native/helloworld-javafx-maven-plugin/helloworld-javafx-maven-plugin Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:221) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:248) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:209) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:675) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$1(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) ... 1 more helloworld-javafx-maven-plugin Error invoking method. helloworld-javafx-maven-plugin Failed to launch JVM I need to replace also libprism_common.so, libprism_es2.so and libprism_sw.so and the test run correctly. I'm not an expert with javapackager, but I think the problem here is the same like https://bugzilla.redhat.com/show_bug.cgi?id=1700927#c2. I will close this bug for the same reason: "Currently there are no plans to ship a portable OpenJDK as part of the Fedora distribution via RPMs".
Hi, I suggest to reopen. this bug is not about other distributions or having a portable JDK. The application compiled with fedora's jdk/openjfx doesn't work on fedora. Without any special command line options, it fails "randomly" (reproducible per project, but I don't know what project differences are important; in my case, it was adding a 30megabyte file to my resulting jar). With the "-Dsun.io.useCanonCaches=false" option it fails all the time. The bug is not in upstream openjfx because in upstream jdk, tzdb.dat is a file. However, in fedora's jdk it was changed to a symlink. Thus (like what is done for the cacert file which is also changed from a file to a symlink and hence not copied [1]), the bug must be fixed in fedora by patching the relevant places where this file is used. [1] https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/blob/master/f/pr2888-openjdk_should_check_for_system_cacerts_database_eg_etc_pki_java_cacerts.patch
Fixing this bug requires understand why the upstream openjfx decided not to copy symlinks, and choosing between the two solutions: - copy tzdb.dat (and maybe other symlinked files ?) - patch the relevant executables to look for tzdb.dat in the system folder instead of JAVA_HOME
Hi, correct me if I'm wrong: 1. you don't specify -Dsun.io.useCanonCaches=false and then in some cases (described above) the generated bundle doesn't start? 2. if you specify -Dsun.io.useCanonCaches=false, it fails always to start? I modified for testing the LinuxAppBundler to accept symlinks and it works only on fedora in both cases (useCanonCaches true or false). For patching the relevant part to look for tzdb.dat in system filder instead of $JAVA_HOME, I think isn't on openjfx part but in openjdk instead. it seems to be that the file canonicalization cache is disabled by default now on openjdk-12 (see https://bugs.openjdk.java.net/browse/JDK-8207005) I could build the modified version and then you could test on your environment if it solves your problem (on fedora system)?
Hi, > correct me if I'm wrong: > 1. you don't specify -Dsun.io.useCanonCaches=false and then in some cases (described above) the generated bundle doesn't start? > 2. if you specify -Dsun.io.useCanonCaches=false, it fails always to start? You are right. Copying all symlinks means that tzdb.dat will be copied. I'm pretty confident that your patch fixes the problem. However, all other symlinks will now be copied. What is the impact of this ? Why did the openjfx team exclude symlinks ?
I will make a build for testing. I don't know why specifically the symlinks is excluded for openjfx (performance reason like as mentioned here https://bugs.openjdk.java.net/browse/JDK-8207005). I think the impact will be small for openjfx.
For info, Here are the symlinks in oracle's jdk8 jdk1.8.0_212/bin/ControlPanel -> jcontrol jdk1.8.0_212/jre/bin/ControlPanel -> jcontrol jdk1.8.0_212/jre/lib/amd64/server/libjsig.so -> ../libjsig.so jdk1.8.0_212/man/ja -> ja_JP.UTF-8 Here are the symlinks in fedora's openjdk8: fedorajdk/bin/javafxpackager -> /usr/lib/jvm/openjfx/bin/javafxpackager fedorajdk/bin/javapackager -> /usr/lib/jvm/openjfx/bin/javapackager fedorajdk/jre/lib/amd64/libdecora_sse.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so fedorajdk/jre/lib/amd64/libglassgtk2.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libglassgtk2.so fedorajdk/jre/lib/amd64/libglassgtk3.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libglassgtk3.so fedorajdk/jre/lib/amd64/libglass.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so fedorajdk/jre/lib/amd64/libjavafx_font_freetype.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so fedorajdk/jre/lib/amd64/libjavafx_font_pango.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so fedorajdk/jre/lib/amd64/libjavafx_font.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so fedorajdk/jre/lib/amd64/libjavafx_iio.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so fedorajdk/jre/lib/amd64/libprism_common.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so fedorajdk/jre/lib/amd64/libprism_es2.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so fedorajdk/jre/lib/amd64/libprism_sw.so -> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so fedorajdk/jre/lib/amd64/server/libjsig.so -> ../libjsig.so fedorajdk/jre/lib/ext/jfxrt.jar -> /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar fedorajdk/jre/lib/javafx.properties -> /usr/lib/jvm/openjfx/rt/lib/javafx.properties fedorajdk/jre/lib/jfxswt.jar -> /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar fedorajdk/jre/lib/security/cacerts -> /etc/pki/java/cacerts fedorajdk/jre/lib/tzdb.dat -> /usr/share/javazi-1.8/tzdb.dat fedorajdk/lib/ant-javafx.jar -> /usr/lib/jvm/openjfx/lib/ant-javafx.jar fedorajdk/lib/javafx-mx.jar -> /usr/lib/jvm/openjfx/lib/javafx-mx.jar fedorajdk/lib/packager.jar -> /usr/lib/jvm/openjfx/lib/packager.jar
Please try with those RPMs build for testing here https://koji.fedoraproject.org/koji/taskinfo?taskID=36275468.
I tested your rpms, they fix the problem. in addition to bundling the necessary tzdb.dat file, there is also a duplicated libjsig.so file: $ find /tmp/old -name libjsig.so /tmp/old/runtime/lib/amd64/libjsig.so $ find /tmp/new -name libjsig.so /tmp/new/runtime/lib/amd64/libjsig.so /tmp/new/runtime/lib/amd64/server/libjsig.so And there is a whole new folder: $ tree /tmp/new/runtime/lib/security/ /tmp/new/runtime/lib/security/ ├── blacklisted.certs ├── cacerts ├── java.policy ├── java.security ├── nss.cfg └── policy ├── limited │ ├── local_policy.jar │ └── US_export_policy.jar └── unlimited ├── local_policy.jar └── US_export_policy.jar 3 directories, 9 files This is about 250kbytes Jon
I preparing the new build but I have some problems for the 32 bits version (Upsteam Eclipse project has dropped support for 32bit architectures) and I need eclipse-swt for building openjfx. I'm working on it.
FEDORA-2019-e3b2a95f86 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3b2a95f86
FEDORA-2019-6d4081993b has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d4081993b
openjfx-8.0.202-8.b07.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d4081993b
openjfx-8.0.202-8.b07.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3b2a95f86
openjfx-8.0.202-8.b07.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
openjfx-8.0.202-8.b07.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.