Deprecation warnings on Java 25: Restricted and deprecated methods used in Truffle and JS ScriptEngine

[e-filchenko-bosh]

Describe GraalVM and your environment :

• GraalVM version or commit id if built from source: 24.1.2
• CE or EE: CE
• JDK version: JDK 25
• OS and OS Version: macOS Sonoma 14.4.1
• Architecture: amd64
• The output of java -Xinternalversion:

openjdk 25.0.1 2025-10-21 LTS
OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.1+8 (build 25.0.1+8-LTS, mixed mode, sharing)

Have you verified this issue still happens when using the latest snapshot?
Yes, the issue is reproducible with the latest release (24.1.2).

Describe the issue
After migrating my project to Java 25 and using GraalVM JS ScriptEngine (org.graalvm.js:js-scriptengine:24.1.2), I started receiving warnings about restricted and deprecated methods being called from Truffle libraries.
Specifically, java.lang.System::load and sun.misc.Unsafe::objectFieldOffset are used internally, which will be blocked in future Java releases.
This may break compatibility with future Java versions.

Code snippet or code repository that reproduces the issue
var engine = new ScriptEngineManager().getEngineByName("JavaScript");
Dependencies (pom.xml):

<dependency>
    <groupId>org.graalvm.polyglot</groupId>
    <artifactId>polyglot</artifactId>
    <version>24.1.2</version>
</dependency>
<dependency>
    <groupId>org.graalvm.polyglot</groupId>
    <artifactId>js</artifactId>
    <version>24.1.2</version>
    <type>pom</type>
</dependency>
<dependency>
    <groupId>org.graalvm.js</groupId>
    <artifactId>js-scriptengine</artifactId>
    <version>24.1.2</version>
</dependency>

Expected behavior
No warnings about restricted or deprecated methods from Truffle or GraalVM libraries.
Full compatibility with Java 25 and future Java versions.

Notes
Related issue: oracle/graaljs#970

Additional context

Details

Depending on my run configuration, I see different combinations of warnings for the same code: (Warning 1 + Warning 2) or (Warning 1 + Warning 3).

Warning 1:

WARNING: A restricted method in java.lang.System has been called 
WARNING: java.lang.System::load has been called by com.oracle.truffle.runtime.ModulesSupport in an unnamed module (file:/.../truffle-runtime-24.1.2.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

Warning 2:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called 
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.oracle.truffle.api.nodes.NodeClassImplNodeFieldData(file:/.../truffle−api−24.1.2.jar)
WARNING: Please consider reporting this to the maintainers of class com.oracle.truffle.api.nodes.NodeClassImplNodeFieldData 
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release

Warning 3:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.oracle.truffle.api.dsl.InlineSupport$UnsafeField (file:/.../truffle−api−24.1.2.jar)
WARNING: Please consider reporting this to the maintainers of class com.oracle.truffle.api.dsl.InlineSupport$UnsafeField
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release

[chumer]

Thank you for the report.

Truffle requires deep integration with the host VM and therefore needs both native access and unsafe access (for the time being). There is no replacement in the JVM that addresses our requirements. This means that unsafe and native accesses are likely here to stay.

That said, there are ways to obtain non-deprecated unsafe access through a native access method, and we plan to adopt those in future releases.

For now, you need to pass the following JVM options:

--enable-native-access=org.graalvm.truffle

to enable native access for Truffle.

If you are running without the module system, you need to pass:

--enable-native-access=ALL-UNNAMED

To temporarily suppress warnings until we can obtain unsafe access through native means, you also need to pass:

--sun-misc-unsafe-memory-access=allow

temporarily.

This should allow you to run without warnings.

[e-filchenko-bosh]

Thank you so much for your help and for sharing a solution to this issue. We really appreciate your support. Our team will be following future updates to the project closely.