Guidance on Java JRE Usage for PST Parsing in Mac OS Application– Code Signing & App Store Compliance

This entire setup (JAR + JRE) is bundled within the Contents/Resources directory of the macOS app

Don't use the Resources directory for executable code. Maybe try the "Frameworks" folder instead? I know it says "Frameworks", but it is an older directory that is likely to be more compatible with something unusual like this. According to the current documentation, there is also a "PlugIns" and a "Library" folder that are possible. But I think these are intended for specific artifacts. The "Helpers" folder is another catch-all possibility.

A better idea might be the new Swift/Java interoperability project.

A better idea might be the new .

That’s cool tech, but you still need a Java runtime to run the Java side of this.

Is on-demand download of a custom runtime … permitted …?

That’s a policy question, and thus outside of my wheelhouse. I can only point you to the App Review Guidelines. Clause 2.4.5(iv) seems pretty clear to me, but I don’t work for App Review and thus can’t make definitive statements about their policies.

On the technical side, Etresoft already pointed you at Placing Content in a Bundle, which is the definitive answer to such questions. Note this comment:

If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems.

Java runtimes are notorious for not following the rules in that doc, and thus often produce weird problems like this.

In many cases you can get around those by manually signing your code, as explained in Creating distribution-signed code for macOS. That’s because macOS is often more forgiving than our tools when it comes to code signing. However, that’s a bunch effort and doesn’t guarantee a solution. You may still have tooling issues, and it’s also possible that you might encounter runtime issues in future versions of macOS [1].

One specific thing to watch out for here is bundling native code in JAR files. The App Store distribution process re-signs your code [2], and it’s unable to do that if the code is in a JAR file. If your Java code relies on native code in JAR files, you’ll need to rework that packaging so that the native code is outside the JAR file, which allows App Store to re-sign it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] While I’m not aware of any such changes pending, this sort of thing has happened before. For example, there’s the whole Separate read-only and read/write content section in Embedding nonstandard code structures in a bundle. Historically cross-platform apps might’ve been able to get away with writing data back to the app’s bundle, but that technique was completely broken by app bundle protection. For more on that change, see the link in Trusted Execution Resources.

[2] Something I talk more about in TN3161 Inside Code Signing: Certificates.

That’s cool tech, but you still need a Java runtime to run the Java side of this.

That's a disappointment.

I hereby retract that recommendation.

Instead, I suggest trying the Aspose Email for .NET package. I know nothing about .NET, but it seems there are some ways to incorporate .NET libraries without a .NET runtime. I sure don't understand .NET versions. But there is a much larger community of people using .NET on macOS than Java.

Thanks @DTS Engineer and @Etresoft But the exact problem here is something else relating to security issues.

I did try the approach of moving it into the PlugIns directory and still App store expected me to codesign all the dylibs and the binaries with entitlements. The problem arises when I had to add the com.apple.security.app-sandbox entitlement to the java executable to avoid thie error.

ITMS-90296: App sandbox not enabled -  The following executables must include the 'com.apple.security.app-sandbox' entitlement with a Boolean value of true in the entitlements property list: [[com.app.sample.appstore.pkg/Payload/Sample.app/Contents/PlugIns/Java.runtime/Contents/custom-jre-universal/bin/java]] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app.

So when i added an entitlement file and codesigned the java executable inside my PlugIns directory and after which when i run the java executable I get this error, which was working fine until i codesigned it with entitlements (containing com.apple.security.app-sandbox as true).

Exception in thread "main" java.lang.InternalError: Error loading java.security file
	at java.base/java.security.Security.initialize(Unknown Source)
	at java.base/java.security.Security.lambda$static$0(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.security.Security.<clinit>(Unknown Source)
	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(Unknown Source)
	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(Unknown Source)
	at java.base/sun.security.util.SecurityProperties.includedInExceptions(Unknown Source)
	at java.base/sun.security.util.SecurityProperties.<clinit>(Unknown Source)
	at java.base/sun.security.util.FilePermCompat.<clinit>(Unknown Source)
	at java.base/java.security.AccessControlContext.<init>(Unknown Source)
	at java.base/java.security.AccessController.createWrapper(Unknown Source)

Any help relating to how to resolve this entitlements issue will be of great help.

Also @Etresoft we already had the license for Aspose Email for Java which is why we decided to go with this instead of the .NET to avoid buing a newer license.

Regards,

Maaz Hussain

I did try the approach of moving it into the PlugIns directory and still App store expected me to codesign all the dylibs and the binaries with entitlements.

Certainly.

Here is an ancient post that may still be relevant for you: https://stackoverflow.com/questions/16960662/embedding-a-java-runtime-into-a-sandboxed-cocoa-mac-app

It may be possible to just slap entitlements on the binary. I don't know. Another option could be to integrate the runtime into your executable.

And finally, take another look at the license costs for the .NET version and keep that in mind as your burn hours trying to get Java to work.

after which when i run the java executable I get this error

Yeah. Unfortunately there isn’t a trivial fix for such things. When you enable App Sandbox you significantly change the process’s runtime. If you take code that wasn’t designed to run in the sandbox and run it in the sandbox, you will encounter all sorts of issues. I expect that all of those issues have fixes — that is, Java isn’t doing anything that’s fundamentally incompatible with the sandbox — but investigating the issues and applies the fixes is a lot of work. Moreover, that work requires you to understand the code, both for the Java runtime and the Java code being executed by that runtime.

And that last bit is the kicker. I’m happy to help you fix sandbox incompatibilities but that help assumes that you understand your code, and this case your code means all of Java O-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"