Repository navigation
Depend on hdf5-platform instead of only the macosx-arm64 natives - #11
Merged
Merged
Conversation
janelia-jhdf5 had compile dependencies on org.bytedeco:hdf5 and on its macosx-arm64 natives only. Every consumer therefore got native HDF5 for Apple Silicon and nothing else: on Linux, Windows and Intel Macs the first HDF5 call fails with an UnsatisfiedLinkError unless the consumer adds the right natives jar themselves. Depend on org.bytedeco:hdf5-platform instead, which brings the classes plus the natives for every published platform; JavaCPP loads the ones for the platform it runs on, and -Djavacpp.platform=<platform> restricts the build to one. This also makes the test-only natives profiles redundant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 6, 2026
mkitti
added a commit
that referenced
this pull request
Oct 13, 2026
Merges, via the top of the stack, PRs #1 through #19: HDF5 2.2.0 via org.bytedeco:hdf5 (#1, #2), vendored cisd:base (#3-#7), the upstream TestNG suite and fixes (#8, #9, #12, #15), CI (#10, #16), hdf5-platform (#11), native-library loading (#13, #14), imported cisd:base tests (#17), README (#18) and benchmarks (#19). Each PR's commits are preserved.
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
1 participant
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.
Stacked on #10. Fixes the native libraries janelia-jhdf5 gives its consumers.
Problem
janelia-jhdf5 had two compile dependencies on HDF5:
org.bytedeco:hdf5: the Java classes, without native code.org.bytedeco:hdf5:macosx-arm64: the native libraries for Apple Silicon only.Everything that depends on janelia-jhdf5 (Fiji plugins, BigDataViewer, applications) got exactly those two jars. On Apple Silicon that works. On Linux, Windows and Intel Macs the classpath had HDF5's Java classes but no native code for the running platform, so the first HDF5 call failed with an
UnsatisfiedLinkErrorunless the consumer added the right natives jar themselves. Every platform also bundled an unused 4.2 MB macOS jar.Change
Depend on
org.bytedeco:hdf5-platforminstead. It's bytedeco's standard aggregate of the HDF5 classes plus the natives for every published platform: android arm64/x86_64, linux arm64/ppc64le/x86_64, macOS arm64/x86_64 and windows x86_64. JavaCPP loads the ones matching the platform it runs on.The test-only natives profiles added in #10 are removed;
hdf5-platformcovers them.Trade-off
The natives jars are 1.8–9.5 MB each, roughly 40 MB together, plus JavaCPP's own natives. Consumers who target one platform can build with
-Djavacpp.platform=linux-x86_64(or another platform), which bytedeco's platform poms honour to pull in only that platform's natives.Testing
dependency:listshows the main jar, the 8 natives jars andjavacpp-platform.🤖 Generated with Claude Code