[Checkers] [Pag] Progress Report

[Matt Papi]

Mahmood,

> __ Debugging Binary Distribution __
> The binary distribution has been broken for awhile apparently.  For some
> reason, our binary distribution of the javac compiler does not actually
> override classes in rt.jar.  Matt reversed the change in Messager (the class
> in rt.jar).

That's not entirely accurate. Of course, that's not your fault, since
I never really explained the situation to anyone other than Mike. Here
are some details, in case it comes up again in the future:

The problem was technically with the installation instructions and not
with the distribution itself -- in my environment settings, the binary
distribution worked just fine, and the release script's sanity checks
have been passing for the binary distribution from the beginning
because the release script sets up its environment first (classpath
and bootclasspath, primarily). We could have added a bunch of text to
the documentation explaining the situtation and not modified any code.

However, the rationale behind my decision to remove the method in
Messager was as follows:

1. There would have to be separate instructions for different kinds of
environments (command-line, various IDEs, etc.) and the installation
instructions would probably have become long and messy.

2. We (I) probably shouldn't have modified a public JSR 269 interface
in the first place.

3. That added method in Messager was the only change we made to any
class that would end up in rt.jar. Reverting the change meant that all
compiler changes are in classes that end up in tools.jar. (I say "end
up in" because the OpenJDK langtools build file produces javac.jar,
which mashes together classes that are in both tools.jar (from the
JDK; classes from "com.sun") and rt.jar (from the JRE; classes from
"javax") in Sun's binary distributions). Of course, as Jonathan
Gibbons pointed out, maybe a better solution would be to use the
jre/lib/endorsed directory. In either case, though, restricting all of
our compiler changes to tools.jar makes things simpler and obviates
excessive classpath modification.

I should point out that now SourceChecker has to use JavacMessager, a
compiler-internal class, to do reporting, which is a bit less than
ideal. The plan is to propose the official addition of the method that
we removed to the JSR 269 API, so that eventually it will be present
in the underlying JDK and we won't have the potential for NoSuchMethod
errors, and at that time we can have SourceChecker use Messager once
again.

- Matt