[Nitjsefnie]

Summary

Packages musl-native JNI libraries in the uber JAR so cedar-java works on Alpine/musl systems without a manually supplied library, and proves it in CI by authorizing on Alpine.

Related Issues and Pull Requests

Fixes #335
Relates to #264 (the earlier musl request; its 2024 attempt predated JNE's musl support and was closed by its author)

Changes

• Added x86_64-unknown-linux-musl and aarch64-unknown-linux-musl to rustLibraryTargets, packaged under JNE's musl resource paths (linux_musl/x86_64, linux_musl/aarch64)
• compileFFI builds musl targets with RUSTFLAGS=-C target-feature=-crt-static: Rust's static musl CRT cannot produce a cdylib, so the musl libraries link dynamically against musl's libc.so, which Alpine provides
• New NativeLibraryPackagingTests derives the expected resource paths by driving JNE's own NativeTarget.resolveResourcePaths and requires a packaged library at a candidate path for all four Linux combinations (musl/gnu, x86_64/aarch64)
• The reusable workflow uploads the uber JAR plus runtime dependency JARs from the Ubuntu leg, and a new Alpine smoke job runs the real uber JAR inside eclipse-temurin:17-alpine with CEDAR_JAVA_FFI_LIB unset, asserting a permit and a forbid through BasicAuthorizationEngine.isAuthorized

Testing

• Built both musl cdylibs locally with the repository's exact toolchain (Rust 1.89.0, cargo-zigbuild 0.22.1, zig 0.11.0): both succeed, and readelf -d shows only NEEDED [libc.so] with zero GLIBC_ symbols for both
• Drove the real jne-4.5.3.jar to confirm JNE's candidate paths (jne/linux_musl/{x64,x86_64,amd64}/... and jne/linux_musl/{arm64,aarch64}/...), so the packaged directory names resolve on a musl host
• Full fork CI green on the branch head adf0ee14b38c57de43927461f2a59cf70b289ada: FFI cargo test, FFI formatting, Gradle build with the new packaging test, javadoc, and the Alpine smoke (permit: allowed=true, forbid: allowed=false)

Follow-ups / Known Limitations

• The Alpine smoke runs on the hosted x86_64 runner; aarch64 musl is build- and packaging-verified but not runtime-loaded in CI
• The musl libraries link musl's libc dynamically and are loadable only on musl systems, which is the point of the packaging

Footer

Generated by GPT-6.1 Sol (implementation), GPT-6 Astra (review), GLM-5.3-Flash (brief, verification)

[Nitjsefnie]

Heads-up: this branch lives in an organization-owned fork, and GitHub doesn't let maintainers push to those. If anything needs changing, just say so here and I'll make the change on this branch right away.