<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html; charset=windows-1252"
<body bgcolor="#ffffff" text="#000000">
I think your interpretation is arguably over-zealous.<br>
The exact text, from the current edition of JLS is<br>
<blockquote type="cite">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:<br>
The type is referred to by code in other compilation units of the
package in which the type is declared.<br>
The type is declared public (and therefore is potentially
accessible from code in other packages).</blockquote>
The host system is given a <i>choice</i> of whether to enforce a
restriction, so you can't say it is unconditionally "_not_ legal".<br>
Nevertheless, this is an interesting part of the spec, and I agree
we should move towards enforcing it. <br>
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.<br>
On 03/16/2012 05:26 PM, Dan Smith wrote:
<pre wrap="">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:
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-v1/">http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-v1/</a>
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?