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

  xxxxx@xxxxx   2000-08-10

N/A

Verified as submitted.

  xxxxx@xxxxx   2000-08-10

Pending resolution of a spec issue; the specified changes are not backwards compatible.

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

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

  xxxxx@xxxxx   2001-02-05

I use classes that are in an unnamed namespace that were 
written by somebody else (i.e. I don't have the source 
code).  I can't move them from the unnamed namespace into a 
named namespace (can I? How? Decompile, add a "package" 
statement and recompile?)

The how does a class in a named namespace access a class in 
an unnamed namespace?

idl declarations not enclosed in any modules map into the 
(Unnamed ) Java global scope which has no visible package. 
Ref. ftp.omg.org/pub/docs/ptc/00-01-08.pdf.  For example:
//IDL

module Example{...}

//generated Java
import Example;
...
 which occurs for many idl files. It would be beneficial if 
idlj had the option to define a prefix for the idl 
declarations not enclosed inside modules.

Very nice "feature".
Now we have to change a lot of our production code.
And don't tell me that's not in the spec.
A lot of books, samples (even a few from SUN) use that
feature.
Well, I hope that this will be that last thing we need 
change because of 1.4.

I understand the need for a cleanly specified language, but 
this decision is crazy. Sun did us all a favor when they 
introduced the @deprecated mechanism to support backwards 
compatability and also move the language forward. Why did 
they abandon this philosophy when it came to refining the 
language spec? 

I was trying out someone else's device driver in my 
application. But they had placed the code in the unnamed 
namespace. Took me half a day to find the problem, rewrite 
the JNI code, and compile the thing. They were using 1.3 
and didnt know there was a problem.

Please: do the developer community a favor and opt for 
compatability over zealotry. 

What a horrible decision!  How am I supposed to import other
packages that I only have class files for, like LVG?
And also, the compiler dosen't even give you a good message
about it!  If your going to make a stupid change to compiler
behavior like this, you could at least have had a message
from the compiler saying that this has changed.  It takes a
long time to track down bugs like this.  

Another workaround is using jikes for compilation. So far
this one does not complain about this.

What a "feature"!
Will the coming 1.4+ versions support this backward 
compatability again?  Otherwise we have to fall back to 1.3.

You might want to change the following text from 
http://java.sun.com/docs/books/tutorial/java/interpack/usepk
gs.html

For your convenience, the Java runtime system automatically 
imports three entire packages: 

The default package (the package with no name) 
The java.langpackage 
The current package 

Shouldn't the language disallow placing classes in the
unnamed package since they become invisible to classes in
named packages?

If the JLS has been "updated" to say that you cannot import a name in an unnamed package, you may want to put it online; There is nothing (in §7.5 and §6.7) that indicates default package imports are not legal in the version on http://java.sun.com/docs/books/jls/second_edition/html/

This sucks.

I agree. :)

Also, the examples included in downloadable "Java Web 
Services Tutorial v1.1" 
(http://java.sun.com/webservices/downloads/webservicestuto
rial.html) need to be fixed.

The sample DATE application:
1) MyDate.java & MyLocales.java - both classes are not 
packaged.
2) index.jsp:
    <%@ page import="MyLocales" %>
3) date.jsp:
    <%@ page import="MyDate,MyLocales" %>

<%@ page import="MyDate,MyLocales"> is translated to:
. . .
import MyDate;
import MyLocales;
. . .
which generates error in JDK 1.4.x.

Would you fix Sun's "The Java Web Services Tutorial"
(http://java.sun.com/webservices/docs/1.0/tutorial/doc/JSPIn
tro2.html#65749):
-------------------------------------------------
The jsp:include element sends a request to another page 
(date.jsp) and includes the response in the response from the 
calling page.
<%@ page import="java.util.*,MyLocales" %>
-----------------------------------------------
This definitely won't work with MyLocales in unnamed 
namespace.

the 'new' gCPortal no longer compiles because of this. I don't 
know what makes you more stupid, publishing code from your 
website that uses unnamed namespaces or breaking the 
compiler. I guess both, well done Sun!

 Please, just fix this compiler bug and stop trying to
explain the unexplainable.

Hi

This is a regression from inter language (i.e. not only 
Java)  communication point of view...I have a compiler 
of a language let say LANG that generates bytecode 
classes without package, i.e in the default package 
name space.

Now, with this fix, I can't anymore integrate Java class 
that are using LANG classes....In particular, I cannot 
run JUnit testing anymore!!!

I am offended at the justification for this compiler 
change. There are a great number of production classes 
defined in the default namespace (nevermind it is a bad 
idea to do so- and Sun has been warning people not to)!  I 
don't understand how this change provides a benifit 
greater than the real pain it causes. 

Any work arounds to this possible, i mn if we still want to import unnamed namespaces???
Pary

Backwards compatible?  

hm, i think this is good thing on balance