pathing issue

[Andreas Svenkson]

With the following directory structure:

pathtest\pack\User.Java
pathtest\Iface.java

Consider the following code:

package pack;

public class User implements Iface {
	public static void main(String[]args) {
		System.out.println("Implementer running");
	}
}

public interface Iface {}

Attempting to compile within directory "pathtest" with: javac -cp . pack/User.java
...does not work, due to the compiler being unable to find Iface.

As you can see, Iface is not in a specific package, and the source is placed in the root of the classpath. So, how does one correctly reference the interface Iface, from within class User? Is it even possible when the interface does not belong to a named package?

// Andreas

[Ikpefua Jacob-Obinyan]

Andreas Svenkson wrote:
As you can see, Iface is not in a specific package, and the source is placed in the root of the classpath. So, how does one correctly reference the interface Iface, from within class User? Is it even possible when the interface does not belong to a named package?
// Andreas

Ikpefua wrote:

Andreas here I am again! ...I tried it too and it did NOT work! , your guess is as good as mine, I tried it again, this time declaring Iface in a package and it worked!.

Again if you put the interface inside the same .java file as the class User, it 'obviously' compiles!. At the moment let us beleive that these are the ONLY options -there might be more- but not that I know of.

[Andreas Svenkson]

Hi again Ikpefua

Indeed, the problem is only when you do not declare a package for the interface. Putting it inside a package obviously solves the problem, since you can reference it via its complete pathname, including the package it belongs to.
And like you say, putting it in the same source file as User.java works too, but that's really the same thing since it is then put in package 'pack'.

I find it strange that it would not be possible to reference it without it belonging to a package though :/ I would have thought that putting in the root directory of the classpath would make it possible to find the interface, but...

If anyone got a clue how to reference this interface, declared without a package, please let me know.

// Andreas

[Stephan van Hulst]

It's impossible and with good reason.

Every class should be in a named package. The default package is only provided for small test programs. If your program spans multiple packages, it no longer qualifies as a small test program.

[Andreas Svenkson]

Sure, in a practical setting I have no doubt that every class will be in a package - I'm just surprised there's no way to reference one that isn't, even if it is located in the root of the classpath (which seems a suitable place for a non-package declared class to be).

But thanks for confirming that it's impossible

// Andreas

[Stephan van Hulst]

Because that would mean adding another special feature to the language; one that would support a situation that is not recommended in the first place.

[Mala Gupta]

Stephan,

I am sure there more to this question!

Most of the books claim that all non packaged classes and interfaces are defined in a 'default' package, which is imported in all classes and interfaces, automatically by Java. Then why this massive injustice when it comes to a packaged class extending/ implementing a non-packaged class/ interface?

cheers
Mala

[Stephan van Hulst]

Mala Gupta wrote:Most of the books claim that all non packaged classes and interfaces are defined in a 'default' package, which is imported in all classes and interfaces, automatically by Java.

I think you either misread, or those books are wrong. The default package is never imported automatically, and there is also no way to import it manually.

[Ikpefua Jacob-Obinyan]

Stephan van Hulst wrote:

Mala Gupta wrote:Most of the books claim that all non packaged classes and interfaces are defined in a 'default' package, which is imported in all classes and interfaces, automatically by Java.

I think you either misread, or those books are wrong. The default package is never imported automatically, and there is also no way to import it manually.

Ikpefua wrote:

@Stephan, what Mala said 'rings-a-bell' I think I read something similar somewhere, I will search for the full details and make it available A.S.A.P.
I advice that we should NOT come to an ABSOLUTE conclusion at the moment, lets research first and find out how default packages behave, one thing is for sure DEFAULT packages exists, the question is how do they operate?? I dont remember, however I will get the details, Thanks.

[Seetharaman Venkatasamy]

Stephan is correct. you cant mix non-packaged class and packaged class. if you do , you will get compilation error!

[Mala Gupta]

Stephan,

Got it! We can't import a non-packaged class/ interface because the interpretation of a 'default package' isn't uniform. Here's what Java Language Specs have on Unnamed packages (http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2)

7.4.2 Unnamed Packages
A compilation unit that has no package declaration is part of an unnamed package.

Note that an unnamed package cannot have subpackages, since the syntax of a package declaration always includes a reference to a named top level package.
As an example, the compilation unit:

class FirstCall {
public static void main(String[] args) {
System.out.println("Mr. Watson, come here. "
+ "I want you.");
}
}

defines a very simple compilation unit as part of an unnamed package.

An implementation of the Java platform must support at least one unnamed package; it may support more than one unnamed package but is not required to do so. Which compilation units are in each unnamed package is determined by the host system.

In implementations of the Java platform that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is observable at a time, namely the one that is associated with the "current working directory." The precise meaning of "current working directory" depends on the host system.

Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development.

Here's also a bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4989710) on static import of members of unpackaged classes/ interfaces, which has been reported as 'not a defect'.

cheers
Mala

[Andreas Svenkson]

Seetharaman Venkatasamy wrote:Stephan is correct. you cant mix non-packaged class and packaged class. if you do , you will get compilation error!

With the risc of being overly clear, I'd just like to say that you CAN mix them, but not both ways. We have no problems reaching any packaged class FROM a non-packaged class. The "issue" is only to reach non-packaged classes/interfaces from PACKAGED classes. So the "problem" only exists one way.

I'd also like to add that I still fail to see the reason why any compiler/JVM would not look in the root directory of the classpath defined, but I guess it's a way of reinforcing that we should use packages.

// Andreas