Initial proof of concept for implementation of -Xlint:hiddenclass

[Jonathan Gibbons]

Dan,

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.

-- Jon





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.
>
> —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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20120316/26988db5/attachment.html