Initial proof of concept for implementation of -Xlint:hiddenclass

[Dan Smith]

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

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

My interpretation is that the compiler may enforce "the restriction," or not, but can't choose to enforce just part of "the restriction."  ("The restriction" means "it is an error if A and (B or C).")  The situation we have right now is that javac enforces just part of the restriction.

I get that the alternative reading would be that the system can choose to enforce "it is an error if A and B" and/or "it is an error if A and C".  But, reading carefully, I don't think the text actually says that.

It's a moot point, though.  It's plausible that either interpretation describes what we think the spec _should_ say; once we've decided what it's supposed to say, we can tweak the language as necessary.

—Dan