Repository navigation
Java extraction on Windows emits native-access warnings from SubstResolver on JDK 24+ #23044
Description
When extracting a Java project on Windows with JDK 24+, CodeQL emits JVM warnings because com.semmle.util.files.SubstResolver calls System.load without native access enabled.
Extraction succeeds, but the unexpected warnings can cause failures in build wrappers that parse compiler output as diagnostics.
Steps to reproduce
On Windows, with CodeQL CLI v2.27.4 and JDK 24+ on PATH, create Hello.java:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello");
}
}Compile normally as a control:
javac Hello.java
Remove-Item Hello.classThen compile under CodeQL tracing:
codeql database create codeql-db --language=java --source-root=. --command="javac Hello.java"Actual behavior
Normal compilation does not emit the warning. Compilation under CodeQL emits the following warning block:
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by com.semmle.util.files.SubstResolver in an unnamed module (file:/C:/codeql_temp/codeql3000/distribution/codeql/java/tools/semmle-extractor-java.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
Expected behavior
CodeQL extraction should not introduce native-access warnings into otherwise successful Java compilation.
JEP 472 introduced these warnings by default in JDK 24. This also raises a forward-compatibility concern when native access becomes denied by default.
Relevant source
SubstResolver.java loads canonicalize.dll on Windows using System.load.
Activity
jketema commentedon Nov 7, 2026
Hi @akoeplinger,
From our side this should fail safe when native access gets denied by default, and will then only negatively impact you when you depend on
substin your build. Unfortunately, we cannot switch to more modern/safer approaches here to get access to some native Windows interfaces, as we need to support JVMs as far back Java 9 (will change to Java 11 in January, but that's still too old). We can have a look a silencing the error by passing--enable-native-access=ALL-UNNAMED.akoeplinger commentedon Nov 7, 2026
@jketema thanks, yeah I think passing --enable-native-access would be the preferred option if possible (not sure if the way you inject into the process allows modifying JVM options?)
A few other ideas:
substcommand and parse its output to check if any drive mappings are active before loading the native libjketema commentedon Nov 9, 2026
I've opened an internal PR that should address this.
I'd prefer to stay away from parsing output of a command line utility, as that output might not be stable.
I believe we have this already, or at least the possibility to insert additional JVM options via an environment variable, but something more permanent is preferred.
jketema commentedon Nov 10, 2026
Fix merged. This should land in CodeQL 2.27.5, which should be released within the next two weeks.