app is not opening after build on MacOS Big Sur

[philburk]

Thanks for providing this example! Writing Java desktop apps is great but distributing them is not easy.

I followed the directions with one deviation. In 3build, the command:

JAVA_HOME=`/usr/libexec/java_home -v 1.8`

was pointing to an Applet plugin area so I changed it to:

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents/Home

Then 3build printed:

Using base JDK at: /Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk Using base JDK at: /Library/Java/JavaVirtualMachines/jdk1.8.0281.jdk Preparing Info.plist: /var/folders/7/wf1y8g4s77x691dlj1b5nqn40000gn/T/fxbundler1438665154597910595/macosx/Info.plist Using default package resource [Bundle config file] (add package/macosx/Info.plist to the class path to customize) Using default package resource [icon] (add package/macosx/MacJavaProperties.icns to the class path to customize) Creating app bundle: /Users/phil/Work/JavaPackagerTextArea/release/bundles/MacJavaProperties.app Config files are saved to /var/folders/7_/wf1y8g4s77x691dlj1b5nqn40000gn/T/fxbundler1438665154597910595/macosx. Use them to customize package.

If that succeeded, it created "release/bundles/MacJavaProperties.app"

I verified that the MacJavaProperties.app was created but when I entered this nothing happened.

 open release/bundles/MacJavaProperties.app/

No error messages. No windows opening. I suspect the additional security in Big Sur is blocking it.

I think we may need to add an icon so we can right click and override the security block.

Another possibility is Java version mismatch. My default Java is JDK14 so the compile was using JDK14. I am happy to try some variation.

[philburk]

I can right click on your JAR file and run it using JavaLauncher. It opens the window and displays lots of variables.

I tried removing the JAVA_HOME line from 3build and got:

java 14 2020-03-17 Java(TM) SE Runtime Environment (build 14+36-1461) Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing) Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: deploy failed at com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:324) at com.sun.javafx.tools.packager.Main.main(Main.java:476) Caused by: java.lang.RuntimeException: Cannot determine which JRE/JDK exists in the specified runtime directory. at com.oracle.tools.packager.mac.MacAppBundler.createMacRuntimeRules(MacAppBundler.java:976) at com.oracle.tools.packager.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:132) at com.oracle.tools.packager.mac.MacAppBundler.extractMacRuntime(MacAppBundler.java:282) at com.oracle.tools.packager.BundlerParamInfo.fetchFrom(BundlerParamInfo.java:116) at com.sun.javafx.tools.packager.bundlers.BundleParams.getRuntime(BundleParams.java:262) at com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:331) at com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:318) ... 1 more Caused by: com.oracle.tools.packager.ConfigException: Cannot determine which JRE/JDK exists in the specified runtime directory. ... 8 more

If that succeeded, it created "release/bundles/MacJavaProperties.app"

[philburk]

I got it to work. I changed my system JAVA_HOME by switching the soft link to point to JDK8.

cd /Library/Java/JavaVirtualMachines/
ls -l
sudo rm Current
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents Current

Then I reran 1compile.sh, 2makeJar and 3build. They ran OK and then the open worked.

If I remove the setting of JAVA_HOME in 3build, or use the original command with "/usr/libexec/java_home", then I get the error "Cannot determine which JRE/JDK exists in the specified runtime directory.".

[alvinj]

Hi @philburk. Thank you for this, and I’m glad you got it to work! I really need to update this project, because Oracle changed the tooling, and as of Java 14 they have a new jpackage tool that I describe here:

• https://alvinalexander.com/java/how-use-jpackage-command-java-14-jdk-sdk/

So if you’re okay with using Java 14, if only for the build process, that command should make things easier. What I mean by that is that you can still create your jar file with Java 8 or 11, and then do the packaging with Java 14.

All the best, Al