Initial proof of concept for implementation of -Xlint:hiddenclass

Dan Smith daniel.smith at
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 from 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 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