dylib java,libAppleScriptEngine.dylib的Java公证失败，二进制文件使用的SDK早于10.9 SDK

End of 2019 I had basic notarization of my Java 8 application working, on February 2020 Apple tightened the rules regarding notarization and this stopped my application from being notarized. Since I needed to move to Java 11 anyway I switched to Java 11 as I understood that this could be notarized ok and made necessary code changes but still having some problems.

Specifically there is an option in my application to communicate with Apple Music app (formerly iTunes) using Applescript to communicate with it. Prior to Java 11 this has always been possible via use of libAppleScriptEngine.dylib that comes with MacoS JDK/JRE and applescript jar (originally provided by Apple and provides interface so can be looked up by javax.scripting).

In Java 11 libAppleScriptEngine.dylib has been removed as documented in Oracle JDK 11 Migration Guide, with no replacement offered.

Removed AppleScript Engine

The AppleScript engine, a platform-specific javax.script

implementation, has been removed without any replacement in the JDK.

The AppleScript engine has been mostly unusable in recent releases.

The functionality worked only in JDK 7 or JDK 8 on systems that

already had Apple's version of the AppleScriptEngine.jar file on the

system.

However, if I deploy my application with libAppleScriptEngine.dylib in the MacOS folder of my package the applescript continues to work fine running on Java 11.

But unfortunately (although signing verification of the app gives no error) notarization fails with following error

{

"logFormatVersion": 1,

"jobId": "224840dd-15ec-45a2-8cd0-b046dab3bccb",

"status": "Invalid",

"statusSummary": "Archive contains critical validation errors",

"statusCode": 4000,

"archiveFilename": "songkong-osx.dmg",

"uploadDate": "2020-04-14T11:50:17Z",

"sha256": "b4d3a808a11a342b748901e5b6df5d628fb76a936ebe67ed5b2558cee5f268f7",

"ticketContents": null,

"issues": [

{

"severity": "error",

"code": null,

"path": "songkong-osx.dmg/SongKong.app/Contents/MacOS/libAppleScriptEngine.dylib",

"message": "The binary uses an SDK older than the 10.9 SDK.",

"docUrl": null,

"architecture": "x86_64"

}

]

}

So is there a way round this ?

This is the end of the build script

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"

/usr/bin/codesign --timestamp --options runtime \

--entitlements /Users/paul/code/jthink/songkong/songkong.entitlements \

--sign "Developer ID Application: P Taylor" \

--force --deep --verbose /Applications/SongKong.app

/usr/bin/codesign -vvv --deep --strict /Applications/SongKong.app

spctl -a -t exec -vv /Applications/SongKong.app

cd /Users/paul/code/jthink/SongKong

/usr/local/bin/dmgcanvas /Users/paul/code/jthink/SongKong \

/dmgCanvas_songkong.dmgCanvas /Users/paul/songkong-osx.dmg \

-v SongKong -identity "Developer ID Application: P Taylor"\

-notarizationAppleID [email protected] \

-notarizationPassword password -notarizationPrimaryBundleID songkong

I tried replacing the version of libAppleScriptEngine.dylib with one from the latest Oracle Java 8 build Oracle 8u241 but made no differcne. I am surprised it is built against the old sdk, because I had heard it was now possible to notarize a Java 8 build.

Can I elect not to sign the libAppleScriptEngine.dylib file in order to allow notarization to succeed ?

解决方案

Because Oracle Java 8 is linked to OSX 10.8.3, it will not pass Apple notary.

The open-source Liberica JDK 8u252 https://bell-sw.com/pages/java-8u252/ is built for OSX 10.9, so that will work. The release notes are in error, stating the minimum macOS version is 11.8, which does not exist.

otool -l Library/Java/JavaVirtualMachines/liberica-jdk-8.jdk/Contents/Home/jre/lib/libAppleScriptEngine.dylib reports:

cmd LC_VERSION_MIN_MACOSX

cmdsize 16

version 10.9

sdk 10.14

There is no work-around which allows an Oracle Java 8 binary to be notarized.

Notarization only works for binaries linked against macOS 10.9 or later.

Java 8 itself is built on the 10.7.5 sdk. That it is a recent update of Java8 you are using does not change that backwards compatibility. Java 8 was originally released during 10.9 Mavericks and was compatible with the then-still-supported 10.7.5 Lion. Any update of Java 8 is intended to support 10.7.5 Lion and was linked against it.

Java 9, released during 10.12 Sierra is backwards compatible to 10.10.

Any unsigned binary executable is also not going to notarize.