default package

Hi,

Thanks for your reply.

Packages are not hierarchic in the sense that the spec indicates:

<<There is no special access relationship betwen a package "oliver" and another pakcage named "oliver.twist -- the code in a package named oliver.twist has no better access to the types declared within package oliver than code in any other package>>

But packages are hierarchic in the sense that a package has members that are subpackages, and those subpackages have members that are subpackages, etc. Ch7 (first page) explains:

"The members of a package are class and interface types...*and* subpackages...". It's the membership relationship I'm interested in, and I described it as hierarchical, but maybe I can describe it differently...

Putting aside the argument that the default package should not be used (which I agree with, but is irrelevant if I were writing a compiler), and staying away from the term "hierarchical", I should rephrase the question:

For each non-compound package name (eg, for each top-level package like "foo" rather than "foo.goo"), is this top-level package a member of the default package?

Thanks,

Will

will608a at 2007-7-28 18:45:26 >

Hi George,

Thanks for your reply.

My reasons for asking questions such as these are mainly just curiousity, a desire to understand the "why" behind what the Java spec says, and the need for greater clarity on some points that seem unclear/ambiguous to me. Even what seems like corner cases or unimportant details can at some later time be useful, so I appreciate any responses from those who are willing to indulge my curiousity. Hopefully others will learn by this too.

In this case, a compile problem for a simple test program got me wondering more about the details of packages, and so I read the spec, Ch 7. The problem was something like this:

//file 1 (default pkg)

import test.Goo;

class Foo {

public static void main(String[] args) {

System.out.println(Goo.x); //**compile error**

}

}

//file2 (default pkg)

class Goo {

public static int x;

}

//file3

package test;

public class Goo {}

The ref to Goo.x failed, and it's interesting to understand why...

If class Goo were located in file1 along with class Foo:

//file 1 (default pkg)

import test.Goo;

class Foo {

public static void main(String[] args) {

System.out.println(Goo.x); //**[b]error[/b]**

}

}

class Goo {

public static int x;

}

//file3

package test;

public class Goo {}

...then this would cause a compile error:

"The import test.Goo conflicts with a type defined in the same file"

Ok, so if I move Goo from file1 to its own file (still in the default pkg) in file2, then there's no conflict but I get a different compile error:

"Goo.x cannot be resolved"

This is apparently because if you import a class from a different package into "your package", and if a class by that simple name already exists within your package (but is located in another file/compilation_unit), then the imported class will shadow the class that's in your package. No problem... you can just disambiguate the class names by using the fully-qualified class name, but you'd need to somehow know that your class is being shadowed, and I don't see an easy way of knowing this, especially if your class and the default class happen to be binary compatible with your code (and thus you won't get compile errors). This problem has nothing to do with the default package, but there is a problem that does...

What happens in the same scenario as the above paragraph, where "your package" is the default package? In that case, I don't see a way to disambiguate the class names because the class in your default package would be shadowed, and to disambiguate and use it you'd need to fully qualified it -- whoops, but the fully-qualified name of a class in the default package is the same as its simple name, so you're stuck.

For the sake of argument, wouldn't it have made sense to design the language so that a class in in "your package" would shadow any class having the same simple name that's imported from a different package, rather than the other way around? Then you'd be able to disambiguate *any* class.

This is one more reason to avoid using the default package, but it would be interesting to know why the current design is the way it is with respect to this kind of shadowing.

Thanks,

Will

will608a at 2007-7-28 18:45:26 >