Build step failing on Java >= 16 when using Error-Prone

[trask]

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make public java.net.URI com.sun.tools.javac.api.ClientCodeWrapper$WrappedFileObject.toUri() accessible: module jdk.compiler does not "opens com.sun.tools.javac.api" to unnamed module @3f0ee7cb
  	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
  	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
  	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:[199](https://github.com/trask/opentelemetry-java-contrib/runs/5491815918?check_suite_focus=true#step:5:199))
  	at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
  	at com.semmle.extractor.java.interceptors.JavacToolInterceptor.getTask(JavacToolInterceptor.java:157)
  	... 57 more

was able to workaround it by adding this to the build step:

env:
  JAVA_TOOL_OPTIONS: "--add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED"

See https://github.com/open-telemetry/opentelemetry-java-contrib/pull/252 for more details, or please ping me and I'm happy to provide any info you need. Thx!

[smowton]

Investigated this and found it isn't specific to Java 17, but it is specific to Java >= 16 in combination with use of Error-Prone.

Roughly what happens: the Gradle Error-Prone plugin notices that we're running Java >= 16 and instructs Error-Prone to fork before attempting to compile any fixes for problems it detects. It adds a bunch of --add-opens directives when forking, but these are sufficient for Error-Prone itself but not for our extractor, which intercepts Error-Prone's use of JavacTool and tries to use a method belonging to module jdk.compiler/com.sun.tools.javac.api.

This will likely apply to any Java process that runs JavacTool, not just error-prone, so the ideal fix would be to add the --add-opens directive requires whenever we see a JVM startup that isn't obviously a direct javac invocation, since it might call JavacTool at some point.

[trask]

thx @smowton! how can I know when this fix is released?

[smowton]

The relevant CodeQL build will roll out to Code Scanning within the next week or so. This will be in CodeQL v2.10.4; at the top of a Code Scanning job in the step "Initialize CodeQL" you can see the version, like

 /opt/hostedtoolcache/CodeQL/0.0.0-20220811/x64/codeql/codeql version --format=terse
  2.10.3