Is there any way to import a class with no package?

[pedrosolorzano]

Hi all:

assuming that the directory (or jar) where the X class is located is already in the CLASSPATH,


X.java:

public class X{
}


Y.java:

package ypkg;

import X;

public class Y{}

Is there any way that Y imports the X class without receive the:

Y.java:3: '.' expected
import X;

error, without making X belongs to a package or Y not belongs to a package?

Thanks in advance for any answer. I'm desperate.

 

[hologram]

Strange, but I do NOT get a compilation error and I can run the program. Tested with jdk1.3.1 and jdk1.4.2 (from within JBuilder)

 

[pedrosolorzano]

Hi hologram:

Thanks for the answer. Look at this:

--------------------------------
bash-2.05$ cat X.java
public class X{
}
bash-2.05$ cat Y.java
package ypkg;

import X;

public class Y{
}
bash-2.05$ javac Y.java
Y.java:3: '.' expected
import X;
^
1 error
bash-2.05$ java -version
java version "1.4.0_00"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_00-b05)
Java HotSpot(TM) Client VM (build 1.4.0_00-b05, mixed mode)
bash-2.05$

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

Maybe the JBuilder somehow imported the X class, I need to know how to do that without using JBuilder or any other IDE. did you put the "import X;" and "package ypkg;" lines?


Thanks in advance for any answer. I am really desperate...

 

[pedrosolorzano]

the cincunflex (^) in the error points to the ;

HELP!!

 

[hologram]

You are right. When I compile manually I get :

D:\java\projects\MyProject\src\com\ecc\swing2>javac -d . Inheritence.java
Inheritence.java:3: '.' expected
import NoPackage;
                ^
1 error

D:\java\projects\MyProject\src\com\ecc\swing2>

But I don't know what JBuilder is doing different. I have looked at the options of javac, but can't find anything.
For me it's time to go to sleep.

 

[hologram]

Have a look at :

http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html

especially 7.4.2 Unnamed packages --> "Current working directory"

 

[hologram]

Finally I found the answer at :

http://developer.java.sun.com/developer/bugParade/bugs/4361575.html

Bug Id 4361575

Votes 0

Synopsis Correct scoping and diagnostics for import declarations

Category java:compiler

Reported Against merlin-beta, 1.3, 1.4

Release Fixed merlin-beta

State Closed, fixed

Related Bugs 4398719, 4419699, 4429674, 4472803, 4491314, 4496720, 4630799, 4648570, 4650921

Submit Date Aug 10, 2000

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

xxxxx@xxxxx 2001-02-05


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

xxxxx@xxxxx 2000-08-10




Workaround None.

Evaluation 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