Script won't launch app when no JRE/JDK is installed

[EasyG0ing1]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:
Script throws errors when launching the app when it has a bundled JRE but no JRE or JDK is installed on the machine.

Steps to reproduce the issue/enhancement:

1. Package an app with a bundled JRE
2. Run it on a Mac that has never had a JDK or JRE installed

What is the expected behavior?
That the app should launch

What is the current behavior?
The app does not run and I receive errors from the script

Do you have screenshots, GIFs, demos or samples which demonstrate the problem or enhancement?
When I launch the application from terminal, I receive this error:

The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

Print: Entry, ":0:JVMVersion", Does Not Exist
Print: Entry, ":0:JVMHomePath", Does Not Exist
283:339: execution error: System Events got an error: A resource wasn’t found. (-192)

When I launch the app using the mouse and the .app icon, I get this error:

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: @rpath/libjli.dylib
  Referenced from: /Applications/PDFUtils.app/Contents/PlugIns/jre/Contents/Home/bin/java
  Reason: no suitable image found.  Did find:
	/Applications/PDFUtils.app/Contents/PlugIns/jre/Contents/Home/bin/../lib/libjli.dylib: code signature in (/Applications/PDFUtils.app/Contents/PlugIns/jre/Contents/Home/bin/../lib/libjli.dylib) not valid for use in process using Library Validation: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)

Binary Images:
       0x10addf000 -        0x10ade2fff +java (18 - 0) <A6E07EF4-6B41-3AC6-A452-94F801DEB828> /Applications/PDFUtils.app/Contents/PlugIns/jre/Contents/Home/bin/java
       0x11588a000 -        0x115925fff  dyld (852.2) <A7924265-DCEF-3515-B28E-3A8279B43E29> /usr/lib/dyld
    0x7fff2a638000 -     0x7fff2a64afff  libz.1.dylib (76) <73C471D3-07CE-307D-A531-92C5D0E4C0E9> /usr/lib/libz.1.dylib

What is the motivation / use case for changing the behavior?
To run Java applications on systems that have no JRE installed.

Please tell us about your environment:

• universalJavaApplicationStub version: 3.2.0
• macOS version: 12.3
• Java version(s): 18

Other information:

I use VMWare to test , and as soon as I install the Java 18 JDK without setting any environment variables at all, the app will launch fine, but when I revert back to my snapshot that has no JDK, I get the above errors.

I did find and I read #93 and based on what I read, this problem was assumed resolved.

[EasyG0ing1]

I found the solution to this problem. The terminal error thrown is a little misleading, as the error thrown when trying to execute the program from the GUI was the error that was most telling:

code signature in (/Applications/PDFUtils.app/Contents/PlugIns/jre/Contents/Home/bin/../lib/libjli.dylib) 
not valid for use in process using Library Validation: mapped file has no Team ID and is not a platform 
binary (signed with custom identity or ad-hoc?)

Since there is no JDK or JRE installed on the machine, then the script has no choice but to look at the packaged JRE in the .app package, and those libraries, being compiled and NOT code signed, makes them illegal to use on modern MacOS. With a pre-installed JDK / JRE, which IS signed and approved for use, the app will run because the script will prefer those library files before the packaged JRE files.

The solution, in my case anyways, was to add a file named entitlements.plist into the same folder as my POM file, then I had to include it in my build script. And in my case, I'm using Java Packager, so I simply needed to add the line

<entitlements>entitlements.plist</entitlements>

To the Mac portion of the execution section.

Here is what entitlements.plist looks like

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>
</plist>

It is that last line <key>com.apple.security.cs.disable-library-validation</key> that somehow instructs the program at execution time, to ignore the fact that those library files are not signed. It's some kind of a loophole that Apple offers developers - only to be used in rare situations when absolutely necessary.

So, with that change being implemented, everything works perfectly!