Initial proof of concept for implementation of -Xlint:hiddenclass

[Louis Tribble]

The term "secondary class" has worked ok for a top-level class whose name does not match the file name. 

The term is not very specific, but in the context of an AST API and of warning messages in an IDE and a standalone static analysis tool, that hasn't been a problem.

The class that matches the file name, if any, is the "primary class".

Louis

On Mar 16, 2012, at 7:24 PM, Jonathan Gibbons wrote:

> 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/20120318/5d27b4d5/attachment.html