(original) (raw)

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