Illegal reflective access warning (Using Java 11)

[smillst]

Using the eisop fork of CF:

export JAVA_HOME=$JAVA_11_HOME
javac -processorpath $CHECKERFRAMEWORK/checker/dist/checker.jar -cp $CHECKERFRAMEWORK/checker/dist/checker-qual.jar -Anocheckjdk -processor org.checkerframework.checker.nullness.NullnessChecker $CHECKERFRAMEWORK/checker/tests/nullness/KeyFors.java

Warning:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.checkerframework.javacutil.Resolver (file:/Users/smillst/jsr308/checker-framework/checker/dist/checker.jar) to method com.sun.tools.javac.comp.Resolve.findMethod(com.sun.tools.javac.comp.Env,com.sun.tools.javac.code.Type,com.sun.tools.javac.util.Name,com.sun.tools.javac.util.List,com.sun.tools.javac.util.List,boolean,boolean)
WARNING: Please consider reporting this to the maintainers of org.checkerframework.javacutil.Resolver
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

org.checkerframework.javacutil.Resolver is used by the FlowExpressionParser to access the element corresponding to FlowExpressions.

The warning can be suppressed by adding -J--add-opens options:

javac -processorpath $CHECKERFRAMEWORK/checker/dist/checker.jar -cp $CHECKERFRAMEWORK/checker/dist/checker-qual.jar -Anocheckjdk -processor org.checkerframework.checker.nullness.NullnessChecker  -Anocheckjdk $CHECKERFRAMEWORK/checker/tests/nullness/KeyFors.java \
-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED \

[mernst]

Should this issue be in the issue tracker of eisop/checker-framework?

[wmdietl]

Note that CheckerMain automatically does this: https://github.com/eisop/checker-framework/blob/master/framework/src/main/java/org/checkerframework/framework/util/CheckerMain.java#L396

So adding all the -J--add-opens flags is only needed if the CF is used without CheckerMain.

Is there anything left to do for this issue or can it be closed?

[smillst]

Given that most build tools do not use CheckerMain, it would make using the framework with Java 9+ easier if -J--add-opens were not required. This shouldn't block merging eisop though, so let's discuss this further at a future meeting.

[wmdietl]

I'm not so worried about the -J--add-opens, as it is for a relatively small number of packages. As these compiler packages are internal, I don't think there is a way around the add-opens. For supporting the annotated JDK, we will need a much larger number of --patch-module directives that people will have to copy into their build files, if they can't use CheckerMain.

[the1derer]

@wmdietl @smillst @mernst

For supporting the annotated JDK, we will need a much larger number of --patch-module directives that people will have to copy into their build files, if they can't use CheckerMain.

One possible solution I could think of is to make our own maven plugin(we already have gradle plugin), this would

• Eliminate the need for the user to add so many -J-add-opens and --patch-module arguments.
• Also, we can just ship only those modules which contain Checker Framework annotations and update --patch-module for new modules added, to the updated version of the plugin.

[mernst]

Creating a Maven plugin is a great idea. I have created an issue to track that enhancement.

We had a Maven plugin once, but it did not work well. Other people have promised to create one, but have not followed through. The fundamental problem is that we have not yet found someone with enough knowledge of Maven internals to create a good plugin.