United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4361575 : Correct scoping and diagnostics for import declarations

Details
Type:
Bug
Submit Date:
2000-08-10
Status:
Closed
Updated Date:
2001-09-20
Project Name:
JDK
Resolved Date:
2001-02-02
Component:
tools
OS:
windows_nt,linux,generic,windows_2000
Sub-Component:
javac
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0,1.4.0
Fixed Versions:
1.4.0 (beta)

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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
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
                                     
2001-02-05
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
                                     
2001-02-05
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)
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta

FIXED IN:
merlin-beta

INTEGRATED IN:
merlin-beta

VERIFIED IN:
merlin-beta3


                                     
2004-06-14



Hardware and Software, Engineered to Work Together