Application exists unexpectedly if packaged using 1.6.4+ #185
Comments
|
Hi @amitjoy! I hope you don't mind, but I've taken the liberty of looking at your project's AFAIK, next line in your config is bundling a JDK with your app: Why don't you let JavaPackager to generate a JRE for your app removing this property? |
If this step doesn't throw any light, try to inspect |
|
@fvarrui Thanks a lot for your quick response. I tried to run the application from command line and surprisingly it works perfectly. The application starts as usual but when I double click on the application icon, it doesn't work. By the way, I have removed the line jrePath property from the configuration as you suggested to let javapackager generate a JRE. |
|
When starting the application by double clicking on it, the following syslog got generated:
I think this is why the application couldn't be started |
|
The following contains all the syslogs while opening the application by double clicking on it: |
|
It seems that the problem is when signing the JRE binaries, so I've been analysing the situation and seen two options (a or b), a) Set I hope it helps! |
|
As you said that it stopped working since v1.6.4, I checked the changelog and found this: This piece of code include "hardened codesign" ( |
|
I have diabled code signing by setting |
|
Try to run it again from command line, please |
|
I've added a new boolean property |
|
I have built the The following contains the syslogs: |
|
I've filtered your syslog output:
Are you using any Apple Developer ID to sign your app? I've got a Mac Mini with Mac OS 10.15 and I'll try your project when arrive at home .... could you give me some instructions in order to build your app, please? |
|
Going back to the beginning: I'm not an expert, but maybe you need to disable security checks on your Mac OS to run your app, or you should sign and notarize it. One question; you said that JavaPackager 1.6.3 worked fine for you ... did you use it on the same system? same Mac OS version? Or have you upgraded your system and then you upgrade JavaPackager from 1.6.3 to 1.6.4/.5? |
|
@fvarrui Thanks a lot for your continuous support. Since macOS Moneterey, the code signing is required as a mandatory step which makes macOS application distribution pretty difficult. Apart from that, code signing is automatically enabled due to my system policy as it is configured by the system admin. That's why code signing cannot be disabled. That's a pain right now. The last successful test I could perform was on 1.6.2 which can generate macOS and linux artifacts pretty easily but in case of windows (if built using Java 17) encounters |
|
It's quite puzzling. I'm sorry I can't help you more, but I don't have a latest generation Mac and I don't have an Apple developer certificate, which costs €99 per year. So, I guess you are not codesigning and notarizing your app with a valid Apple Developer cert and maybe this is the problem. I'm going to ask to another JavaPackager user which had a successful story with it. Maybe he could provide us a step by step guide. |
|
@amitjoy , can your issue be fixed with the following:
so an example <?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>Notice the last one, disable library validation and compare to your initial error of: And you need to check if the JDK that you use is properly signed I think. Old JDKs can be problem maybe? Hope this solves it for you? |
|
Thanks so much Mabula!!! |
|
@amitjoy - I'll take issue with your statement
I've successfully compiled and run MacOS Java apps that run fine without any code signing ... I've tested the .app files with a clean install of Monterey 12.3 in a virtual machine and the app was built and compiled using the latest Java version 18. |
|
@EasyG0ing1 , but..., without code signing (and notarization), your application will never pass the macOS gatekeeper, on latest macOS versions, without telling the user that the software is not safe to use... The user then has to manually approve it in security and privacy settings to get it to run... (which many users struggle with I know for a fact.) So yes, it can still run and work, but it will not give the users of your software a good install experience nor cofirm to the user that your package installation is mature, would you not agree? |
|
@fvarrui - Agreed... but the more I think about it, the only way I was able to get a packaged Java program to run on a machine without a JDK or JRE installed, was to install a JDK or a JRE, then it would run just fine ... but now I'm thinking that the reason why it would run, is because it defaulted to use those Java libraries which ARE code signed and were installed and approved for use ... so the program is basically just "piggybacking" off of previously authorized code... so I spoke too soon on this topic, as it seems that @amitjoy is correct, there is no way to run software that is not signed on Monterey. |
|
Thanks a lot everyone for taking up the issue. I believe to ensure that the app runs everywhere including Monterey, I have to sign and notarize the application. |
|
@amitjoy - I was able to get my app to run on a Mac that has no JRE, WITHOUT signing it, simply by putting the file <entitlements>entitlements.plist</entitlements>... using version 1.6.6 of JavaPackager. Here is <?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>And here is what my Javapackager config looks like in my POM file: <plugin>
<groupId>io.github.fvarrui</groupId>
<artifactId>javapackager</artifactId>
<version>1.6.6</version>
<configuration>
<mainClass>${exec.mainClass}</mainClass>
<bundleJre>true</bundleJre>
<customizedJre>false</customizedJre>
<generateInstaller>true</generateInstaller>
<administratorRequired>false</administratorRequired>
</configuration>
<executions>
<execution>
<id>windows</id>
<phase>package</phase>
<goals>
<goal>package</goal>
</goals>
<configuration>
<platform>auto</platform>
<createZipball>false</createZipball>
<createTarball>true</createTarball>
<macConfig>
<icnsFile>/Users/michael/IdeaProjects/GistFX/src/main/resources/com/redmondsims/gistfx/Assets/mac/GistFX.icns</icnsFile>
<generateDmg>true</generateDmg>
<generatePkg>false</generatePkg>
<volumeName>GistFX</volumeName>
<volumeIcon>/Users/michael/IdeaProjects/GistFX/src/main/resources/com/redmondsims/gistfx/Assets/mac/GistFX.icns</volumeIcon>
<entitlements>entitlements.plist</entitlements>
</macConfig>
</configuration>
</execution>
</executions>
</plugin>I did have a |
|
Including a module-info.java has nothing to do with JavaPackager, as it only provides strong encapsulation, so you can't access classes which are not specifically exported, being checked by the JVM at runtime. JavaPackager copies all dependencies to your app and then analyzes them using jdeps tool in order to know which core modules are required. Some dependencies are modularized, and some others aren't (those are called automatic modules), which usually causes a module not found exception. Then, with those core modules, it generates a customized and reduced JRE using jlink. That was the idea, but this dependency analysis process has to be improved, as jdeps is not working as I expected. |
|
So, when jdeps fails or doesn't work fine, we have to include all core modules in the generated JRE, losing the possibility to bundle a reduced JRE for distribution. Or specify one by one in which core modules our app depends on, and its dependencies, and dependencies of its dependencies, and .... the same recursively (for transitive dependencies) |
|
Branch issue-185 merged into devel (included |
|
@fvarrui - Are you saying that the inclusion of a |
|
Hi @EasyG0ing1! Sorry for my late reply.
Not exactly. I think I didn't explain myself well. JavaPackager analyzes all JARs included with the app (your app JAR and all its dependencies). So, modules required in your
Distribution packages are well built by JavaPackager, but the building process could fail when searching the required modules with Anyway, I think that there are some things in JavaPackager which has to be improved when dealing with modules. For example, after finding required modules, all those which are not core modules should be excluded when running |
|
JavaPackager v1.6.7 released to Maven Central. See changes here. |
I'm submitting a…
Short description of the issue/suggestion:
Build DMG using 1.6.5 (the latest release) but the application cannot be opened after finishing DMG installation on Mac.
It works perfectly with 1.6.3 or any version before it but doesn't work with 1.6.4 and 1.6.5
Steps to reproduce the issue/enhancement:
What is the expected behavior?
Clicking on the application after having it installed from the DMG file, the application opens normally
What is the current behavior?
Clicking on the application after having it installed from the DMG file, the application exits unexpectedly
Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Other information (e.g. related issues, suggestions how to fix, links for us to have context)
If you are wondering why I am not using jpackage, there is a strong reason for it. I have been banging my head around about a month but the application after having installed from the DMG built by jpackage cannot be opened at all. It can only be opened if I start the application from command line. But it works perfectly if I use JavaPackager. That's why I had to switch to JavaPacakger once again.
The text was updated successfully, but these errors were encountered: