Initial proof of concept for implementation of -Xlint:hiddenclass

[Jonathan Gibbons]

Fredrik,

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 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:
> http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-v1/
>
> 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
>