Fixing build for custom bug patterns with JDK 11

[MatanSabag]

Background:

We maintain a custom Error Prone bug pattern library used throughout our organization. After migrating to Java 11 and updating Error Prone from 2.10.0, builds fail with "cannot find symbol" errors related to classes in the com.sun.tools.javac.code package. Additionally, I see the error:

package com.sun.tools.javac.code is declared in module jdk.compiler, which does not export it to the unnamed module.

Potential Solution:
I'm considering adding the following to build.gradle:

compileJava {
  options.compilerArgs += [
    '--add-opens', 'jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED'
  ]
}

Questions:

1. Will this change require downstream projects consuming our library to make the same build.gradle modification?
2. Are there better alternatives to this approach, considering its potential drawbacks?

Examples of code usage:

Some examples to classes I use are: com.sun.tools.javac.code.Symbol.MethodSymbol, com.sun.tools.javac.code.Symbol.VarSymbol, com.sun.tools.javac.code.Type, com.sun.tools.javac.tree.JCTree.JCExpression, com.sun.tools.javac.tree.JCTree.JCIdent, com.sun.tools.javac.tree.JCTree.JCNewClass

[Thomas Broyer]

Is this about compiling your custom bug pattern? or using it?

This plugin is about using Error Prone, so only the latter is considered in scope. If you're in the former case, then I would apply the same --add-opens and --add-exports that are needed to run Error Prone (and that this plugin applies); see the full list at https://errorprone.info/docs/installation

[MatanSabag]

Thanks for your help, I'll try to do what you suggested here and on Slack and return with results.

[Thomas Broyer]

Closing as it seems to be out of scope here, but feel free to comment back with your findings, that might help others in the future (and is publicly searchable, and durable, contrary to Slack)