Initial proof of concept for implementation of -Xlint:hiddenclass

Jonathan Gibbons jonathan.gibbons at
Fri Mar 16 08:03:00 PDT 2012


Good start.

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 
"hidden class".

-- Jon

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 refers to class B defined in
> 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?
> //Fredrik

More information about the compiler-dev mailing list