libAppleScriptEngine.dylib的Java公证失败,二进制文件使用的SDK早于10.9 SDK [英] Java Notarization of libAppleScriptEngine.dylib failing with The binary uses an SDK older than the 10.9 SDK

查看:265
本文介绍了libAppleScriptEngine.dylib的Java公证失败,二进制文件使用的SDK早于10.9 SDK的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

2019年底,我对Java 8应用程序进行了基本的公证,到2020年2月,苹果收紧了有关公证的规则,这阻止了我对应用程序的公证.因为无论如何我都需要迁移到Java 11,所以我切换到Java 11,因为我知道这可以公证,可以进行必要的代码更改,但是仍然存在一些问题.

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.

具体地说,我的应用程序中有一个选项,可以使用Applescript与 Apple Music 应用程序(以前称为iTunes)进行通信.在Java 11之前,这始终可以通过使用MacoS JDK/JRE和applescript jar(最初由Apple提供并提供接口,因此可以通过javax.scripting查找)附带的libAppleScriptEngine.dylib来实现.

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).

在Java 11中,如《 Oracle JDK 11迁移指南》 ,未提供替代版本.

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

删除了AppleScript引擎

Removed AppleScript Engine

AppleScript引擎,特定于平台的javax.script 实现,已删除,无需在JDK中进行任何替换.

The AppleScript engine, a platform-specific javax.script implementation, has been removed without any replacement in the JDK.

AppleScript引擎在最新版本中几乎无法使用. 该功能仅在以下系统上的JDK 7或JDK 8中有效: 上已经有Apple版本的AppleScriptEngine.jar文件 系统.

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.

但是,如果我在软件包的MacOS文件夹中使用libAppleScriptEngine.dylib部署应用程序,则applescript仍可以在Java 11上正常运行.

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"
    }
  ]
}

那么这有办法吗?

这是构建脚本的结尾

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 paultaylor@jthink.net \
   -notarizationPassword password -notarizationPrimaryBundleID songkong

我尝试用最新的Oracle Java 8构建 Oracle 8u241 中的一个替换libAppleScriptEngine.dylib的版本,但是没有区别.我很惊讶它是针对旧的sdk构建的,因为我听说现在可以对Java 8构建进行公证.

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.

为了允许公证成功,我可以选择不对libAppleScriptEngine.dylib文件签名吗?

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

推荐答案

由于Oracle Java 8已链接到OSX 10.8.3,因此不会通过Apple公证.

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

  • 开源 Liberica JDK 8u252
  • 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报告:

      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
      sdk 10.14


没有解决方法可以对 Oracle Java 8 二进制文件进行公证.


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

  • Java 8本身是建立在10.7.5 sdk上的.它是您正在使用的Java8的最新更新,不会改变向后兼容性. Java 8最初是在10.9小牛期间发布的,并且与当时仍受支持的10.7.5 Lion兼容. Java 8的任何更新都旨在支持10.7.5 Lion,并已与之链接.

  • 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.

在10.12 Sierra中发布的Java 9向后兼容10.10.

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

这篇关于libAppleScriptEngine.dylib的Java公证失败,二进制文件使用的SDK早于10.9 SDK的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆