3

I was able to use ZuluFX 8 with javapackager on Windows. However, on a Mac I get this error:

Bundler Mac Application Image skipped because of a configuration problem: Cannot determine which JRE/JDK exists in the specified runtime directory.
Advice to fix: Point the runtime directory to one of the JDK/JRE root, the Contents/Home directory of that root, or the Contents/Home/jre directory of the JDK.

It's pretty easy to just move the package into Contents/Home but I doubt that will work as it seems there is no JRE bundled with the Mac version of ZuluFX 8. Is this something that can be worked around?

Shai Almog
  • 51,749
  • 5
  • 35
  • 65
  • Can you please elaborate which command produces this error? I was able to successfully run javapackager from ZuluFX build: `~/fxtest/zulu8.36.0.1-ca-fx-jdk8.0.202-macosx_x64/bin/javapackager -createjar -appclass chapterEleven.SimpleApp -outdir dist -outfile SimpleApp.jar -srcdir build/classes` – Sergey Grinev Mar 14 '19 at 16:14
  • I use the Ant script from netbeans to do the build. I think that what you did was generate a package with a different JRE you have installed. Open that package and look inside, is the JRE inside from Zulu? It seems this doesn't work on Windows either. The script ran but the resulting application still used the Oracle JRE. – Shai Almog Mar 14 '19 at 20:29

1 Answers1

3

It's pretty easy to just move the package into Contents/Home but I doubt that will work as it seems there is no JRE bundled with the Mac version of ZuluFX 8.

From what I'm seeing, I'm not sure that's correct. The ZuluFx 8 archive for Mac contains a jre directory. I extracted the archive to ~/zuluFX and from there created the Contents/Home directory as required by MacOS and added a symbolic link to said jre directory there. I then set $JAVA_HOME accordingly:

$ pwd
/Users/cody/zuluFX
$ mkdir -p Contents/Home
$ ln -s ../../jre .
$ export JAVA_HOME=~/zuluFX

Then I utilized a simple javapackager example on github to test its usage (I have no other JREs/JDKs installed on this box). The example app simply dumps Java properties and environment variables in a TextArea.

I had to modify the 3build script in the example to comment out its attempt to re-set $JAVA_HOME, but otherwise, it builds successfully, with the following javapackager command:

javapackager \
  -deploy -Bruntime=${JAVA_HOME} \
  -native image \
  -srcdir . \
  -srcfiles MacJavaPropertiesApp.jar \
  -outdir release \
  -outfile ${APP_DIR_NAME} \
  -appclass MacJavaPropertiesApp \
  -name "MacJavaProperties" \
  -title "MacJavaProperties" \
  -nosign \
  -v

When I launch the resulting app, it reports the usage of the azul/zulu jre as expected:

enter image description here

cody
  • 11,045
  • 3
  • 21
  • 36
  • Thanks! Turns out I had the zulu 11 directory open (which has no JRE) and missed that because of the damn remote access font blurriness (that's my excuse for being stupid and I'm sticking to it). Unfortunately this still isn't working for the NetBeans build, I guess we'll need to do it in command line. – Shai Almog Mar 17 '19 at 10:43
  • Unfortunately this approach packages the JDK not the JRE, all attempts I made to package the JRE failed – Shai Almog Apr 01 '19 at 08:08