Add JAR integration test for JDK compatibility

[xerial]

Summary

• Add integration test that verifies snappy-java JAR works in a separate JVM
• Run integration test in CI for all JDK versions (8, 11, 17, 21, 25)
• Test without --enable-native-access flag to show real-world behavior

Details

This PR adds a comprehensive integration test that validates the snappy-java JAR functions correctly when used as a library.

What's included

Integration test script (script/test-jar-integration.sh):

1. Builds the JAR with sbt
2. Compiles a simple test program that uses snappy-java
3. Runs it in a fresh JVM WITHOUT --enable-native-access flag
4. Verifies compression/decompression works correctly
5. Shows any JEP 472 warnings on JDK 24+

CI integration:

• Runs after regular tests for each JDK version
• Ensures the JAR works correctly on JDK 8, 11, 17, 21, and 25

Test program (src/test/resources/integration/SnappyIntegrationTest.java):

• Simple standalone Java program
• Tests basic compression/decompression
• Exit code 0 on success, 1 on failure

Example output (JDK 25)

==========================================
Snappy-Java Integration Test
==========================================
Java version: 25

Building JAR...
Using JAR: target/snappy-java-1.1.10.8-14-3e32cbb4-20251124-1009-SNAPSHOT.jar

Compiling test program...

==========================================
Running test (WITHOUT --enable-native-access flag)...
==========================================
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.xerial.snappy.SnappyLoader
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers

Compressed 96 bytes to 87 bytes
SUCCESS: Hello snappy-java! Snappy-java is a JNI-based wrapper of Snappy

==========================================
✓ Test PASSED (exit code: 0)
==========================================

Key findings

✅ JAR works correctly on all JDK versions - compression/decompression succeeds
⚠️ JDK 24+ shows warnings - expected behavior per JEP 472
ℹ️ Users need --enable-native-access=ALL-UNNAMED - as documented in #702

This test confirms that:

1. The library functions correctly despite warnings
2. Users on JDK 24+ will see warnings unless they add the JVM flag
3. The warnings are informational and don't break functionality

Why no manifest attribute?

We initially tried adding Enable-Native-Access: ALL-UNNAMED to the JAR manifest, but testing showed it does not suppress warnings when snappy-java is used as a library on the classpath. Per JEP 472, that attribute only works for executable JARs launched via java -jar.

Test plan

• Integration test runs successfully locally
• Test passes on JDK 25 (with warnings as expected)
• CI runs integration test for all JDK versions

Run locally: ./script/test-jar-integration.sh

Related to #689

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @xerial, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the user experience for snappy-java users running on JDK 24 and newer by automatically handling native access permissions. It integrates a specific manifest attribute into the JAR, which allows the JVM to grant necessary native access without requiring any manual configuration or command-line flags from the user, thus streamlining deployment and reducing potential friction.

Highlights

• Native Access Warning Suppression: Adds the 'Enable-Native-Access: ALL-UNNAMED' attribute to the JAR manifest to suppress native access warnings on JDK 24+.
• Improved User Experience: Eliminates the need for users to manually add '--enable-native-access=ALL-UNNAMED' command-line flags for snappy-java.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds the Enable-Native-Access: ALL-UNNAMED manifest attribute to handle native access warnings in JDK 24+. The change is straightforward and well-explained. I have one suggestion to improve the robustness of the sbt build configuration by using ++= instead of := to avoid overwriting other package options.

[gemini-code-assist]

While this might work in the current configuration, using := overwrites any previously defined package options. It is safer and more idiomatic in sbt to append to sequence-based settings like packageOptions using ++=. This will prevent potential conflicts with other plugins (like the sbt-osgi plugin enabled in this project) or other settings that might also be adding manifest attributes.

packageOptions ++= Seq(
  Package.ManifestAttributes("Enable-Native-Access" -> "ALL-UNNAMED")
)