JVM's `Type` reported inaccessible after migrating to 2.11.0

[dmdashenkov]

I'm writing a custom check by extending CheckReturnValue and overriding the specializedMatcher() method, so that some unchecked values are allowed.

Here is the bug pattern code:

@AutoService(BugChecker.class)
@BugPattern(
        name = "HandleMethodResult",
        altNames = {"CheckReturnValue", "ResultOfMethodCallIgnored", "ReturnValueIgnored"},
        summary = HandleMethodResult.SUMMARY,
        severity = ERROR,
        linkType = NONE
)
public final class HandleMethodResult extends CheckReturnValue {

    // ...

    @Override
    public Matcher<ExpressionTree> specializedMatcher() {
        var checkReturnValue = super.specializedMatcher();
        var notBuilderSetter = not(builderSetter());
        return allOf(checkReturnValue, notBuilderSetter);
    }

    private static Matcher<ExpressionTree> builderSetter() {
        return MethodMatchers
                .instanceMethod()
                .onDescendantOf(Message.Builder.class.getName())
                .withNameMatching(ACCESSOR_PREFIX);
    }
}

With version 2.10.0, this works just fine. However, with version 2.11.0, a compilation error occurs at the onDescendantOf(..) call:

class file for com.sun.tools.javac.code.Type not found

I presume, this is related to the fact that onDescendantOf(..) has an overload with the com.sun.tools.javac.code.Type in the parameter.

I cannot add --add-exports flags as the doc suggests, since, it seems, Gradle automatically adds the --release flag to the compiler invocation. I don't know if it would help or not.

Is there a reason why this error might occur after the change of the ErrorProne version? If the reason is known, is there a work-around?

I use Gradle 7.3.3, Gradle plugin 2.0.2, and Java 11.

[tbroyer]

Fwiw, Gradle will only pass the --release flag if explicitly set through the task's options.release or if using toolchains, and then only if neither sourceCompatibility nor targetCompatibility is set. See https://github.com/gradle/gradle/blob/a211042f4c98d6369ed4c9194a02a471771ebb7a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/JavaCompile.java#L339-L372

So if you're using toolchains, then explicitly configure a sourceCompatibility or targetCompatibility and you should be able to pass an --add-exports.

[dmdashenkov]

@tbroyer, thanks, that advice was very helpful.

I wasn't able to run compilation right away after adding --add-exports flags listed in the installation doc. However, after noticing that the erroneous class package is not included in that list, I added

--add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED

and now it works.

Summing up, I think, the com.sun.tools.javac.code package should be added to the installation guide linked above. Thank you for your help.

[cushon]

Note that there are two different --add-exports= flags: the runtime JVM flag, and the compile-time javac flag.

The installation docs describe the runtime JVM, because that's what you need to install Error Prone and run the existing checks.

The compile-time javac flag is needed to actually compile Error Prone, or to compile custom checks. Error Prone's own build passes the compile-time javac flag here, and that list includes com.sun.tools.javac.code: https://github.com/google/error-prone/blob/494184bdae43d960f2b827616ce7283d530a882f/pom.xml#L161-L171

I'd be happy to take a PR to improve this in the docs, I think it would be good to mention in the section on writing custom checks: http://errorprone.info/docs/plugins