Initial proof of concept for implementation of -Xlint:hiddenclass

[Fredrik Öhrström]

Second round of implementation:
http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-v2/

When building the openjdk, it outputs 316 warnings like these:
.../ClientHandshaker.java:723: warning: secondary class SupportedEllipticCurvesExtension in …./HelloExtensions.java should not be accessed from outside its own source file


//Fredrik

16 mar 2012 kl. 16:03 skrev Jonathan Gibbons:

> Fredrik,
> 
> Good start.
> 
> 1. It should be sufficient to remove references to the file manager and use something like
> 
>    c.sourcefile == env.toplevel.sourcefile
> 
> to check if the class is in the "right" file.
> 
> 2. I think line numbers are desirable, and would be easy if you move the checkForHiddenAccess from Resolve into Check, and call it from Attr.
> 
> 3. I think a warning per reference is acceptable: it is not necessary to optimize it to a warning per hidden class.
> 
> 4. We'll need a CCC approval for the new Xlint suboption.
> 
> 5. We should check to see if there is a preferred term for what you call "hidden class".
> 
> -- Jon
> 
> 
> 
> 
> On 03/16/2012 05: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/20120912/c7b615f2/attachment.html