Repository navigation
Let an app load its own libjcocoa.dylib instead of the jar's - #47
Merged
Merged
Conversation
The bridge always extracted the libjcocoa.dylib inside its jar to a temp file and System.load()ed it. An app signed with the hardened runtime and without disable-library-validation (Mac App Store and many notarized apps) cannot load that copy, because it is not signed by the app's team. Setting -Dca.weblite.objc.libjcocoa.path to a libjcocoa.dylib now loads that file instead, so such an app can bundle the library and sign it with the rest of the app. With the property unset nothing changes; it is opt-in so an app that happens to carry an older libjcocoa on its library path does not start loading it. LibjcocoaPathTest runs a JVM with and without the property and checks, through dyld, which libjcocoa image the process loaded. CI: drop the pinned Xcode 13.2 (gone from the runners), update the actions, run on Apple Silicon and Intel, and check that the release build of libjcocoa is universal. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SZMcbjtKBCyrRMgkgSipea
shannah
marked this pull request as ready for review
November 11, 2026 19:21
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
RuntimeUtilsalways extracts thelibjcocoa.dylibinside the jar to a temp file andSystem.load()s it. An app signed with the hardened runtime and withoutcom.apple.security.cs.disable-library-validationcannot load that copy, because it isn't signed by the app's team. That covers Mac App Store builds and many notarized apps. So the bridge can't be used in a sandboxed App Store app, including on Apple Silicon, which 1.2 otherwise supports.This came up moving PDF OCR X to Apple Silicon (shannah/pdfocrx#46).
Change
ca.weblite.objc.libjcocoa.path(RuntimeUtils.LIBJCOCOA_PATH_PROPERTY). When set, the bridgeSystem.loads that file and never extracts its own; the app bundleslibjcocoa.dyliband signs it with the rest of the app. A path that isn't a file fails with anUnsatisfiedLinkErrornaming the property.System.loadLibrary("jcocoa")first, because an app with an olderlibjcocoaon its library path would silently start loading it. PDF OCR X has exactly that: an x86_64-only copy from before 1.1.Tests
LibjcocoaPathTeststartsLoadedLibjcocoain a JVM of its own, since the library is loaded once per JVM in the static initializer. It then asks dyld (_dyld_get_image_name) which libjcocoa image the process loaded:java.io.tmpdir, the existing behaviour;UnsatisfiedLinkError.CI
maven.ymlpinnedDEVELOPER_DIRto Xcode 13.2, which current runners don't have. It now:macos-15(Apple Silicon) andmacos-15-intel;libjcocoa.dylibcontains botharm64andx86_64.Release
After merging this needs a release (1.3) to Maven Central for PDF OCR X to depend on it; I haven't touched the version or the publishing setup.
Generated by Claude Code