JDK-4361575 : Correct scoping and diagnostics for import declarations
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.3.0,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,linux,windows_nt,windows_2000 generic,linux,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2000-08-10
  • Updated: 2001-09-20
  • Resolved: 2001-02-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
--- Top.java ---

public class Top {
  public class Inner {}
}

--- Bottom1.java ---

import Top;

public class Bottom1 {}

--- Bottom2.java ---

import Top.*;

public class Bottom2 { }

--- Bottom3.java ---

import Top.Inner;

public class Bottom3 { }

---------------------

% javac Bottom.*

Bottom2.java:1: package Top does not exist
import Top.*;
^
Bottom3.java:1: cannot resolve symbol
symbol  : class Inner  
location: package Top
import Top.Inner;
           ^
2 errors

-----------------------

According to JLS2e 6.3, the scope of the declaration of class Top
is all type declarations in the package to which it belongs, in this
case, an unnamed package including Bottom1, Bottom2, and Bottom3 as
well.

As a result, Bottom1.java is in error, as the declaration
'import Top;' cannot be resolved.  The compiler fails to report
this error.

In Bottom2.java, an analogous error is detected properly.

In Bottom3.java, it appears that the compiler correctly assumes
that the qualified name must begin with a package name, as a type name
cannot be resolved as the first component.  However, the diagnostic
given is quite confusing, as it points to the claimed nonexistence of
a package member when in fact it is the package itself that is missing.

Note that 1.3.0 reports no errors for any of these examples.  The problem
here is that recent fixes in the Merlin development builds aimed at addressing
conformance issues with import declarations are incomplete and/or erroneous.

william.maddox@Eng 2000-08-10

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta VERIFIED IN: merlin-beta3
14-06-2004

SUGGESTED FIX odersky: SOLVED The parser now rejects simple identifiers in import clauses. Also, the error message is changed when the package in an import class does not exist. update: src/share/javac/com/sun/tools/javac/v8/comp/Enter.java (00/12/15 16:02:41 odersky) update: src/share/javac/com/sun/tools/javac/v8/comp/Resolve.java (00/12/15 16:01:57 odersky) update: src/share/javac/com/sun/tools/javac/v8/parser/Parser.java (00/12/15 16:04:16 odersky)
11-06-2004

EVALUATION Verified as submitted. william.maddox@Eng 2000-08-10 Pending resolution of a spec issue; the specified changes are not backwards compatible. neal.gafter@Eng 2000-12-15 OK, this has been integrated and conforms to the latest language spec. WARNING: users will complain. The compiler apparently allowed importing a type from an unnamed namespace, and the specification arguably allowed it as well, and now it is clearly illegal in both the spacification and the compiler. I had to fix a number of cases in JDK code (all examples) and some test cases. neal.gafter@Eng 2001-02-05 The compiler now correctly scopes import declarations. Among other effects of this change, the compiler now rejects import statements that import a type from the unnamed namespace. The compiler used to accept such import declarations before, but they were arguably not allowed by the language (because the type name appearing in the import clause is not in scope). Rather than try to rationalize the specification with the compiler's behavior, the compiler has been brought into line with the specification, and the specification is being clarified to outright say that you can't have a simple name in an import statement, nor can you import from the unnamed namespace. There were ample warnings in the language specification warning against importing names from the unnamed namespace into a named namespace. Those warnings are no longer necessary, as it is outright illegal. This is likely to break lots of code, but virtually all of it is example code rather than production code. To summarize, the syntax import SimpleName; is no longer legal. Nor is the syntax import ClassInUnnamedNamespace.Nested; which would import a nested class from the unnamed namespace. To fix such problems in your code, move all of the classes from the unnamed namespace into a named namespace. neal.gafter@Eng 2001-02-05
05-02-2001

PUBLIC COMMENTS <p>The compiler now correctly scopes import declarations. <p>Among other effects of this change, the compiler now rejects import statements that import a type from the unnamed namespace. The compiler used to accept such import declarations before, but they were arguably not allowed by the language (because the type name appearing in the import clause is not in scope). Rather than try to rationalize the specification with the compiler's behavior, the compiler has been brought into line with the specification, and the specification is being clarified to outright say that you can't have a simple name in an import statement, nor can you import from the unnamed namespace. There were ample warnings in the language specification warning against importing names from the unnamed namespace into a named namespace. Those warnings are no longer necessary, as it is outright illegal. <p>This is likely to break lots of code, but virtually all of it is example code rather than production code. <p>To summarize, the syntax <pre> import SimpleName; </pre> is no longer legal. Nor is the syntax <pre> import ClassInUnnamedNamespace.Nested; </pre> which would import a nested class from the unnamed namespace. <p>To fix such problems in your code, move all of the classes from the unnamed namespace into a named namespace. neal.gafter@Eng 2001-02-05
05-02-2001