JDK 25 compatibility: `native-platform-0.22-milestone-29` triggers restricted method warnings

[OdysseusLives]

Problem Description

When using JDK 25, the native-platform-0.22-milestone-29 library triggers native access warnings due to restricted method calls introduced in JDK 24+. While Gradle has implemented a workaround by adding Enable-Native-Access: ALL-UNNAMED to wrapper and launcher JARs, this is a broad permission that masks the underlying issue in the native-platform library.

Warning Output

Here is an example output:

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by net.rubygrapefruit.platform.internal.NativeLibraryLoader in an unnamed module (file:/<path>/gradle-9.2.1/lib/native-platform-0.22-milestone-29.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Steps to Reproduce

Method 1: Using Custom Gradle Distribution (without wrapper fix)

1. Install JDK 25: sdk use java 25.0.1-zulu
2. Use a Gradle distribution that lacks the Enable-Native-Access: ALL-UNNAMED wrapper fix (added in commit e46b78507e3fa383f9c5af2e06f4b47a8d9c0b98)
3. Set JAVA_HOME to JDK 25: export JAVA_HOME=/path/to/jdk-25
4. Run any Gradle command: ./gradlew clean
5. Observe warnings in console output

Method 2: Direct Library Usage

1. Create a minimal Java project that directly uses native-platform-0.22-milestone-29
2. Call methods that trigger native library loading
3. Run with JDK 25 and observe warnings

Environment

• JDK Version: 25.0.1 (Azul Zulu)
• Gradle Version: 9.2.1 (or any version using native-platform-0.22-milestone-29)
• native-platform Version: 0.22-milestone-29

Root Cause

JDK 24+ introduced JEP 472: Restrict the Use of JNI, which restricts native method calls like java.lang.System::load without explicit native access permissions.

The NativeLibraryLoader class in this library calls System::load without proper native access declarations, triggering these warnings.

Root Cause Location

The issue originates in:

• File: https://github.com/gradle/native-platform/blob/0.22-milestone-29/native-platform/src/main/java/net/rubygrapefruit/platform/internal/NativeLibraryLoader.java#L51
• Method: System.load() call
• Problem: No native access declarations for JDK 24+ compatibility such as with module-info.java

Impact

• User Experience: Creates noise in build output and application logs
• Future Risk: Warnings indicate these calls will be blocked in future JDK releases
• Ecosystem Impact: Forces downstream projects to use broad native access permissions

Current Workarounds

Core Gradle's Temporary Fix

Gradle has implemented a workaround in commit e46b78507e3fa383f9c5af2e06f4b47a8d9c0b98 by adding Enable-Native-Access: ALL-UNNAMED to wrapper and launcher JAR manifests. This suppresses the warnings but grants overly broad native access permissions, which is not ideal from a security perspective.

Long-term Goal

The ideal solution would allow Gradle to remove the broad Enable-Native-Access: ALL-UNNAMED workaround and use more specific native access permissions, improving security posture while maintaining JDK 25+ compatibility.

Related Issues

• gradle/gradle#31625 - Similar issue in the main Gradle repository before that workaround was introduced; looks like still seeing an issue when using Gradle TestKit
• gradle/gradle commit e46b78507e3fa383f9c5af2e06f4b47a8d9c0b98 - Gradle's workaround implementation

References

• JEP 472: https://openjdk.org/jeps/472
• Gradle Distribution Dependency: https://github.com/gradle/gradle/blob/v9.2.1/packaging/distributions-dependencies/build.gradle.kts#L31
• Maven Central: https://mvnrepository.com/artifact/net.rubygrapefruit/native-platform/0.22-milestone-29

[octylFractal]

I am not sure what "more specific native access permissions" you're referring to are, unless you mean targeting it specifically to the native platform module, which would require us to adopt JPMS in Gradle first which is highly unlikely to happen soon. Even if it is that, it would be something for us to enable in Gradle and not here, as libraries do not get control over the relevant flags, so this should be an issue in the Gradle repository.