Initial proof of concept for implementation of -Xlint:hiddenclass

[Dan Smith]

I had this conversation with Jon earlier, but for others who might be interested:

JLS 7.6 has, since the first edition, had a restriction that says, for compilers that choose to care about file names, referring to class B (declared in C.java) from A.java is illegal.  I don't know why this check has never been implemented in javac.

(For the lawyers, I am reading 7.6 as follows: when "packages are stored on a file system", a compiler may choose to enforce file-name restrictions; if it enforces file-name restrictions, i) it must report an error when a public class is declared in a mislabeled file, AND ii) it must report an error when a name references a package-private class that is declared in a different, mislabeled file.)

So, it's _not_ legal, and people have just been getting away with it because of a bug in javac.  Given the widespread abuse of this bug, though, it may be impractical to fix it now.  As a minimum, reporting a warning is a positive development.

—Dan

On Mar 16, 2012, at 5: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
>