Initial proof of concept for implementation of -Xlint:hiddenclass
jonathan.gibbons at oracle.com
Fri Mar 16 08:03:00 PDT 2012
1. It should be sufficient to remove references to the file manager and
use something like
c.sourcefile == env.toplevel.sourcefile
to check if the class is in the "right" file.
2. I think line numbers are desirable, and would be easy if you move the
checkForHiddenAccess from Resolve into Check, and call it from Attr.
3. I think a warning per reference is acceptable: it is not necessary to
optimize it to a warning per hidden class.
4. We'll need a CCC approval for the new Xlint suboption.
5. We should check to see if there is a preferred term for what you call
On 03/16/2012 05:12 AM, Fredrik Öhrström wrote:
> > From the bug:
> Although legal, the use of multiple top level classes in the same file
> is somewhat questionable to begin with, but it is particularly bad when
> in some package class A in A.java refers to class B defined in C.java.
> This requires that at times the files must be compiled together, and
> prevents implicit compilation from locating such "hidden classes".
> Proof of concept impl:
> It seems to detect the problem correctly. And there are a few of these
> in the jdk, it seems, ~100.
> How to do isSameFile test properly?
> How to report each hidden class reference only once?
> Are line numbers neccesary?
> Where to put checkForHiddenAccess?
> Does it cover all possible use cases?
> What else did I miss?
More information about the compiler-dev