WARNING: A restricted method in java.lang.System has been called (JDK24)

[khmarbaise]

Currently the jline-3.26.3 is used in Maven Core which produces a WARNING like this:

$> mvn clean verify 
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.jline.nativ.JLineNativeLoader in an unnamed module (file:/Users/khm/tools/maven/lib/jline-3.26.3.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

This warning is issued while running under JDK24.ea.13

[gnodet]

@khmarbaise Which version of maven ?

[khmarbaise]

I have tested with Maven 4.0.0-beta-4, 4.0.0-beta-3, 3.9.X(all versions), 3.8.X(all versions)... A simple mvn --version also triggers the warning:

mvn --version
$> mvn --version
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.fusesource.jansi.internal.JansiLoader in an unnamed module (file:/Users/khm/tools/maven/lib/jansi-2.4.1.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

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /Users/khm/tools/maven
Java version: 24-ea, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/24.ea.13-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "mac"

The README tells already something like this:

With JLine 3.26, the FFM provider requires JDK 22 with the --enable-native-access=ALL-UNNAMED JVM option.

If I correctly understand the warning which is related to the usage of this methods:
https://download.java.net/java/early_access/jdk24/docs/api/restricted-list.html

[gnodet]

We need to add argument that to the startup scripts.

[khmarbaise]

Wouldn't it be better to go the way that jline detects which JDK it is running under automatically for example via a multi-release jar which handles that ... using FFM (JDK22+) ? (Just an idea... not familiar with the JLine code)...

[gnodet]

I think JLine almost always needs native access, either because of the FFM provider or because it will need to load a native library.
Only the exec provider can work without native, but it's only supported on Unix systems.

[slachiewicz]

Also with other projects, our default validation fails.

[INFO] --- enforcer:3.5.0:enforce (enforce-bytecode-version) @ maven-filtering ---
[INFO] Restricted to JDK 17 yet org.jline:jline:jar:3.26.3:test contains org/jline/terminal/impl/ffm/CLibrary$termios.class targeted to JDK 22

Error: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce (enforce-bytecode-version) on project maven-filtering:
Error: Rule 0: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion failed with message:
Error: Found Banned Dependency: org.jline:jline:jar:3.26.3
Error: Use 'mvn dependency:tree' to locate the source of the banned dependencies.

[gnodet]

Also with other projects, our default validation fails.

[INFO] --- enforcer:3.5.0:enforce (enforce-bytecode-version) @ maven-filtering --- [INFO] Restricted to JDK 17 yet org.jline:jline:jar:3.26.3:test contains org/jline/terminal/impl/ffm/CLibrary$termios.class targeted to JDK 22

Error: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce (enforce-bytecode-version) on project maven-filtering: Error: Rule 0: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion failed with message: Error: Found Banned Dependency: org.jline:jline:jar:3.26.3 Error: Use 'mvn dependency:tree' to locate the source of the banned dependencies.

That's unrelated and I think the detection is too strict. In this case, the JLine FFM provider requires JDK 22, but those classes are optional. Maven can be switched to using individual JLine jars if needed, that may help.

[gnodet]

I have tested with Maven 4.0.0-beta-4, 4.0.0-beta-3, 3.9.X(all versions), 3.8.X(all versions)... A simple mvn --version also triggers the warning:

mvn --version
$> mvn --version
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.fusesource.jansi.internal.JansiLoader in an unnamed module (file:/Users/khm/tools/maven/lib/jansi-2.4.1.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

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /Users/khm/tools/maven
Java version: 24-ea, vendor: Oracle Corporation, runtime: /Users/khm/.sdkman/candidates/java/24.ea.13-open
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "mac"

The README tells already something like this:

With JLine 3.26, the FFM provider requires JDK 22 with the --enable-native-access=ALL-UNNAMED JVM option.

If I correctly understand the warning which is related to the usage of this methods: https://download.java.net/java/early_access/jdk24/docs/api/restricted-list.html

I've raised apache/maven#1718

[gnodet]

Also with other projects, our default validation fails.

[INFO] --- enforcer:3.5.0:enforce (enforce-bytecode-version) @ maven-filtering --- [INFO] Restricted to JDK 17 yet org.jline:jline:jar:3.26.3:test contains org/jline/terminal/impl/ffm/CLibrary$termios.class targeted to JDK 22

Error: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce (enforce-bytecode-version) on project maven-filtering: Error: Rule 0: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion failed with message: Error: Found Banned Dependency: org.jline:jline:jar:3.26.3 Error: Use 'mvn dependency:tree' to locate the source of the banned dependencies.

Raised apache/maven#1719

[gnodet]

Closing this one as there's not much JLine can do for the JDK24 warning and for the enforcer, we need to use individual jars.

[nipafx]

I just stumbled across that JDK warning and the search led me here. Great to see the community noticing and reacting to these changes quickly. 😃👍🏾

I think everybody in this thread is aware, but just in case: On JDK 22 and 23, this message was an error that was triggered by FFM. On 24, it was temporarily downgraded to a warning, so JNI could be onboarded. Specifically, this is the list of restricted methods that trigger the message (once JDK 24 is GA, that link breaks and the list should be here). In some future release, this warning will become an error again (this time including JNI).

To make all this easier to understand for the user, I recommend to place calls to restricted methods in a try-block, where catch prints/logs a message that explains what's going on and what the solution is (~> --enable-native-access) and then rethrows.

Speaking of --enable-native-access, I saw that the README recommends --enable-native-access=ALL-UNNAMED. While this works, it unlocks native access for all code on the class path - something I wouldn't feel comfortable recommending to (my) users as the only option. Since JANSI does come with a module name, why not mention --enable-native-access=org.fusesource.jansi as well?

If there's interest in these changes, I can open a PR.

[norrisjeremy]

I just stumbled across that JDK warning and the search led me here. Great to see the community noticing and reacting to these changes quickly. 😃👍🏾

I think everybody in this thread is aware, but just in case: On JDK 22 and 23, this message was an error that was triggered by FFM. On 24, it was temporarily downgraded to a warning, so JNI could be onboarded. Specifically, this is the list of restricted methods that trigger the message (once JDK 24 is GA, that link breaks and the list should be here). In some future release, this warning will become an error again (this time including JNI).

To make all this easier to understand for the user, I recommend to place calls to restricted methods in a try-block, where catch prints/logs a message that explains what's going on and what the solution is (~> --enable-native-access) and then rethrows.

Speaking of --enable-native-access, I saw that the README recommends --enable-native-access=ALL-UNNAMED. While this works, it unlocks native access for all code on the class path - something I wouldn't feel comfortable recommending to (my) users as the only option. Since JANSI does come with a module name, why not mention --enable-native-access=org.fusesource.jansi as well?

If there's interest in these changes, I can open a PR.

Won't that only work if the offending library is loaded from the module-path?
And thus wouldn't work in this case since the offending library is loaded by Maven on the class-path?

[norrisjeremy]

I just stumbled across that JDK warning and the search led me here. Great to see the community noticing and reacting to these changes quickly. 😃👍🏾
I think everybody in this thread is aware, but just in case: On JDK 22 and 23, this message was an error that was triggered by FFM. On 24, it was temporarily downgraded to a warning, so JNI could be onboarded. Specifically, this is the list of restricted methods that trigger the message (once JDK 24 is GA, that link breaks and the list should be here). In some future release, this warning will become an error again (this time including JNI).
To make all this easier to understand for the user, I recommend to place calls to restricted methods in a try-block, where catch prints/logs a message that explains what's going on and what the solution is (~> --enable-native-access) and then rethrows.
Speaking of --enable-native-access, I saw that the README recommends --enable-native-access=ALL-UNNAMED. While this works, it unlocks native access for all code on the class path - something I wouldn't feel comfortable recommending to (my) users as the only option. Since JANSI does come with a module name, why not mention --enable-native-access=org.fusesource.jansi as well?
If there's interest in these changes, I can open a PR.

Won't that only work if the offending library is loaded from the module-path? And thus wouldn't work in this case since the offending library is loaded by Maven on the class-path?

Apologies, disregard, I misread this from the wrong project.