Initial proof of concept for implementation of -Xlint:hiddenclass
daniel.smith at oracle.com
Fri Mar 16 17:26:45 PDT 2012
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.
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:
> 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