Document JDK 24+ native access requirements #702
Conversation
Add documentation for JEP 472 native access requirements that affect users running snappy-java on JDK 24 or later. Since snappy-java uses JNI to load native libraries, applications running on JDK 24+ must add the --enable-native-access=ALL-UNNAMED JVM flag. Per JEP 472 guidance, this is the application developer's responsibility (not the library's). The new section includes: - Clear explanation of the requirement - Examples for Maven, Gradle, sbt, and command-line usage - Warning message examples users will encounter - Rationale based on JEP 472's "integrity by default" policy No code changes are needed - this is purely documentation to help users understand and address the warnings they see on JDK 24+. Fixes #689 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Summary of ChangesHello @xerial, I'm Gemini Code Assist1! 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 provides essential documentation to address the new native access restrictions introduced in JDK 24 and beyond, as defined by JEP 472. It guides snappy-java users on how to properly configure their applications with the necessary JVM flag to ensure continued functionality and avoid runtime warnings or errors, without altering the library's core implementation. Highlights
Using Gemini Code AssistThe 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
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds important documentation to the README.md file regarding the necessary JVM flags for running snappy-java on JDK 24 and later, due to changes in JEP 472. The documentation is clear and provides useful examples for command-line usage and various build tools. My review includes a couple of suggestions to make the Maven and Gradle examples more comprehensive by mentioning how to apply the JVM flag not just for tests, but also for application execution, which would further improve the documentation's helpfulness for developers.
| **Maven:** | ||
| ```xml | ||
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <configuration> | ||
| <argLine>--enable-native-access=ALL-UNNAMED</argLine> | ||
| </configuration> | ||
| </plugin> | ||
| ``` |
There was a problem hiding this comment.
The provided Maven example only covers the maven-surefire-plugin, which is used for running unit tests. This is a very common use case, but it would be beneficial to also mention that a similar configuration is needed for other execution scenarios, such as:
- Integration tests with
maven-failsafe-plugin. - Running the application with
exec-maven-plugin.
This would help users configure their projects more completely. You could add a short note to clarify this.
| **Gradle:** | ||
| ```gradle | ||
| tasks.withType(Test) { | ||
| jvmArgs '--enable-native-access=ALL-UNNAMED' | ||
| } | ||
| ``` |
There was a problem hiding this comment.
The Gradle example configures the JVM arguments for all tasks of type Test. This is great for testing, but users might also run their application using other tasks (e.g., the run task from the application plugin, or custom JavaExec tasks).
It would be helpful to either mention this or provide an example for configuring application execution as well. For instance, for the application plugin:
application {
applicationDefaultJvmArgs = ['--enable-native-access=ALL-UNNAMED']
}This would provide more comprehensive guidance for Gradle users.
1 participant
Summary
Details
This PR adds comprehensive documentation to help users understand and address the native access warnings they encounter when running snappy-java on JDK 24 or later.
What changed
Why this approach
Per JEP 472 and the official guidance, it is the application developer's responsibility (not the library maintainer's) to enable native access. The
Enable-Native-Accessmanifest attribute is only for executable JARs, not libraries.No code changes needed
This is purely a documentation update. No changes to snappy-java's code are required - users simply need to add the
--enable-native-access=ALL-UNNAMEDJVM flag when running on JDK 24+.Test plan
Fixes #689
🤖 Generated with Claude Code