Minimize exposure of JDK internals

[delanym]

Have you considered adopting a module declaration?

It would allow minimizing the exposure of JDK internals to errorprone, which would surface any abuse of these internals by other third-party libraries/annotation processors.

--add-exports jdk.compiler/com.sun.tools.javac.api=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.file=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.main=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.model=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.parser=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.processing=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.tree=com.google.errorprone
--add-exports jdk.compiler/com.sun.tools.javac.util=com.google.errorprone
--add-opens jdk.compiler/com.sun.tools.javac.code=com.google.errorprone
--add-opens jdk.compiler/com.sun.tools.javac.comp=com.google.errorprone

[cushon]

It seems like the right thing to do eventually, I don't have specific plans on this front.

A couple of notes:

• I think there are some split package issues between the jars, the modularized jar wouldn't map 1:1 to the current jars
• The installation instructions would change to use --processor-module-path, with similar changes to the build system integrations