Initial proof of concept for implementation of -Xlint:hiddenclass
jonathan.gibbons at oracle.com
Fri Mar 16 19:24:12 PDT 2012
I think your interpretation is arguably over-zealous.
The exact text, from the current edition of JLS is
> If and only if packages are stored in a file system (§7.2), the host
> system may choose to enforce the restriction that it is a compile-time
> error if a type is not found in a file under a name composed of the
> type name plus an extension (such as .java or .jav) if either of the
> following is true:
> The type is referred to by code in other compilation units of the
> package in which the type is declared.
> The type is declared public (and therefore is potentially accessible
> from code in other packages).
The host system is given a /choice/ of whether to enforce a restriction,
so you can't say it is unconditionally "_not_ legal".
Nevertheless, this is an interesting part of the spec, and I agree we
should move towards enforcing it.
We need a better name than "hidden class", since hiding is a term that
already exists in JLS, and can already apply to classes, and is not
related to the conditions being described here.
On 03/16/2012 05:26 PM, Dan Smith wrote:
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev