Add compiled universalJavaApplicationStub as option

[AstroPixelProcessor]

I'm submitting a…

• [ X ] bug report
• [ X ] feature request

Short description of the issue/suggestion:
Without using a binary of the universalJavaApplicationStub for macOS packaging, the java Swing JFileCHooser can not access the user's Documents/Downloads/Desktop folders. So I would suggest to add an option to Java-packager in which the user can choose whether to use a script or binary universalJavaApplicationStub. The binary should work always, the script can give issues with for instance JFileChooser. The binary does not an extra dependency: the shc shell compiler:

https://github.com/neurobin/shc

What is the expected behavior?

A working application that passes notarisation with hardened runtime codesigning and with a working JFileChooser.

What is the current behavior?

An application that passes notarisation with hardened runtime codesigning BUT without a working JFileChooser.

Please tell us about your environment:

• JavaPackager version: 1.6.7-SNAPSHOT
• OS version: macOS 11.0.1
• JDK version: Temurin OpenJDK 17
• Build tool:
  • [X ] Maven
  • Gradle

I will submit a Pull Request with my suggestion ;-)

[fvarrui]

JavaPackager uses a modified version of universalJavaApplicationStub; here is the fork. I'm going to create a GitHub Action workflow to compile the script using shc, and then include this modified/compiled version with JavaPackager, adding an option to choose between the compiled or the interpreted version (to keep backward compatibility).

[AstroPixelProcessor]

@fvarrui , excellent, i used your forked universalJavaApplicationStub to test and cofirm it. I was not sure if the text conversion was needed or not from your version, so I did the compile after the text conversion in MacPackager.

Yes, it should be perfectly fine to have a precompiled stub ready in the resources/mac folder.

Making nice progress !

[AstroPixelProcessor]

I now have all my packaging working completely ready for distribution of my project:

• Windows with InnoSetup,
• Linux DEB and RPM and
• macOS DMG for x86_64 and for arm64

You can add my project to your ReadMe as a project that depends on your javapackager:
Astro Pixel Processor - https://www.astropixelprocessor.com/

Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!)

Thank you very much for your work on this ;-) !

[fvarrui]

I now have all my packaging working completely ready for distribution of my project:

• Windows with InnoSetup,
• Linux DEB and RPM and
• macOS DMG for x86_64 and for arm64
  You can add my project to your ReadMe as a project that depends on your javapackager:
  Astro Pixel Processor - https://www.astropixelprocessor.com/

Thank you very much for your work on this ;-) !

Yes, of course. Thanks to you for helping to improve this tool

[fvarrui]

@fvarrui , excellent, i used your forked universalJavaApplicationStub to test and cofirm it. I was not sure if the text conversion was needed or not from your version, so I did the compile after the text conversion in MacPackager.

Yes, it should be perfectly fine to have a precompiled stub ready in the resources/mac folder.

Making nice progress !

Yes, you are right, the script is preprocessed before copying it to the bundle. But I have an idea. Add some new properties to Info.plist (name and relocateJar) that the script will read, and depending on that property, work one way or another, without the need to tune it.

[fvarrui]

I'm going to publish these changes in issue-187. When ready, I'll let you know!

[AstroPixelProcessor]

Great, look forward to it !

[fvarrui]

I've upgraded my universalJavaApplicationStub fork, and now a GitHub Action workflow generates and releases the compiled and the uncompiled version of the script. And now the script doesn't have to be preprocessed, as now it changes its behaviour based on Info.plist properties.

Next step: include both script versions as JavaPackager resources, and add a new property to the plugin what allow to choose which version has to be bundle with the app.

[fvarrui]

What if we include your entitlements.plist file as a JavaPackager resource, so it could be used by default if macConfig.entitlements property is not specified. What do you think about this?

[AstroPixelProcessor]

Hi @fvarrui excellent, just so I understand this, the compiled script will still be dynamic based on the Info.plist properties? That is really great ;-)

I agree, both the script .sh and the compiled binary should be available.
You can even make a universal binary that includes x86_64 and aarch64 binaries if Github can compile for both targets? Like:
tofi86/universalJavaApplicationStub@bc61236
I have tested this and it works perfectly. It ensures that the compiled version will run on all platforms today, but also in the future when Apple might not include support for x86_64 in the compiler at some point ?

"What if we include your entitlements.plist file as a JavaPackager resource"
Yes, for sure, I think it will help many to get started quickly without encountering problems with their apps not running... These runtime exception entitlements are quite important to be able to run java apps properly while having the hardened runtime enabled in signing which is a must for notarization to be accepted by Apple. And then refer in your ReadMe to what these entitlements mean relating to codesiging : https://developer.apple.com/documentation/security/hardened_runtime

[fvarrui]

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified.

Not tested yet!

[EasyG0ing1]

@fvarrui

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified.

Not tested yet!

How do I test this? Did you push it to the repository?

[AstroPixelProcessor]

@fvarrui do you need me to test it ? I will see if I can do this today or tomorrow ;-)

[fvarrui]

@fvarrui

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified.
Not tested yet!

How do I test this? Did you push it to the repository?

Hi @EasyG0ing1!
Just follow next steps to install JavaPackager 1.6.7-SNAPSHOT to your local Maven repo:

git clone https://github.com/fvarrui/JavaPackager --branch issue-187
cd JavaPackager
./gradlew publishToMavenLocal

[fvarrui]

@fvarrui do you need me to test it ? I will see if I can do this today or tomorrow ;-)

Yes ... great, thanks! I've just tested with SCRIPT, X86_64 and UNIVERSAL, and default entitlements, and all seems to be working fine. But your feedback will be welcomed!

[fvarrui]

Branch issue-187 merged into devel.

[kerner1000]

I now have all my packaging working completely ready for distribution of my project:

• Windows with InnoSetup,
• Linux DEB and RPM and
• macOS DMG for x86_64 and for arm64

You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/

Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!)

Thank you very much for your work on this ;-) !

Hi there, may I ask how to bundle both aarch64 and x86_64?

[fvarrui]

JavaPackager v1.6.7 released to Maven Central. See changes here.

[kerner1000]

Hello @AstroPixelProcessor , Do you package a JRE into your Bundle? If so, how do change the embedded CFBundleIdentifier inside the java binary?

[fvarrui]

I now have all my packaging working completely ready for distribution of my project:

• Windows with InnoSetup,
• Linux DEB and RPM and
• macOS DMG for x86_64 and for arm64

You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/
Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!)
Thank you very much for your work on this ;-) !

Hi there, may I ask how to bundle both aarch64 and x86_64?

Sorry, I miss this question. It's not possible if you bundle a JRE with your app, as it's compiled for an specific system architeture. Otherwise, you can set macStartup=SCRIPT|UNIVERSAL

[fvarrui]

I think @AstroPixelProcessor can throw more light than me about this.