basic package/class visibility question

[Joe Boman]

I have two separate .java files Top.java and Bottom2.java which live in the same directory and the directory is specified in my CLASSPATH. The classes compile and run without incident.
Here's my question: How can Top have visibility when Bottom2 extends Top? Top has only default (package) access and no packages are specified in either file.

class Top {
	public Top() {}
	public Top(String s) {  System.out.print("B"); }
}

public class Bottom2 extends Top {
	public Bottom2(String s)  {System.out.print("D"); }
	public static void main(String [] args) {
		new Bottom2("C");
	System.out.println(" ");
	}
}

[Campbell Ritchie]

Top is only visible in its package.
The problem is, you haven’t given it a package name. That means both those classes are in the unnamed package, and are visible to other Java code in that same unnamed package.

[Joe Boman]

Hello Campbell, You wrote:
Top is only visible in its package.
The problem is, you haven’t given it a package name. That means both those classes are in the unnamed package, and are visible to other Java code in that same unnamed package.

My response:
I am not planning to code a package statement in this particular scenario. A little more background: My question surfaced when pondering an SCJP practice test question. I first checked the classes for visibility and realized I don't really understand why these types of examples always compile successfully. Yes I realize they compile because I do it all the time.

As a result, I have two questions:

1. Why does the Top class have visibility when Top and Bottom2 are in the same file (Bottom2.java)?

2. Why does the Top class have visibility when Top is in a different file? (The original question)

[Jeff Verdegan]

Joe Boman wrote:1. Why does the Top class have visibility when Top and Bottom2 are in the same file (Bottom2.java)?

Because they're in the same package. And also, I think, because they're in the same "compilation unit" (roughly, source file).

2. Why does the Top class have visibility when Top is in a different file? (The original question)

Becauset they're in the same package.

"No package" is the same package as "no package" for determining accessibility.

[Campbell Ritchie]

The visibility has nothing to do which file the code is in.
I suggest you draw a diagram of the packages you have got, maybe like a Venn diagram. Now write the names (if any) against the packages. Now try drawing circles to show the visibility of the different classes. Obviously that will become a right mess if you have more than three or four classes.

[Jeff Verdegan]

Campbell Ritchie wrote:The visibility has nothing to do which file the code is in.

I seem to remember something from the JLS about visibility in "compilation units," which usually came down to .java files. That was a long time ago though, so I might be remembering wrong, or it might have changed. That's not really relevant here though. Just thought I'd mention it.

[Joe Boman]

Hello again Campbell,

I re-read your original explanation a few more times and detected you had typed the word "the" in front of unnamed package. As in -- the "unnamed package". I now realize unnamed package is an actual concept in Java. In the interim I had taken this question offline and learned the unnamed package is also known as the default package. Do I understand that correctly?

Along the way I found someone who wrote the following:
, classes with no package declarations are implicitly part of an "unnamed package", often also called "default package". However, since it's not possible to import classes from an unnamed package and since the language spec explicitly allows implementations to have different rules about whether and how classes in unnamed packages are visible to each other, it's generally a good idea to put all classes in named packages except for experimental code.

[Campbell Ritchie]

Joe Boman wrote:Hello again Campbell,

. . . I now realize unnamed package is an actual concept in Java. In the interim I had taken this question offline and learned the unnamed package is also known as the default package. Do I understand that correctly?

Yes. It’s all in the Java Language Specification. It is really easy to read. That last statement was a dreadful lie

Along the way I found someone who wrote the following:
, classes with no package declarations are implicitly part of an "unnamed package", often also called "default package". However, since it's not possible to import classes from an unnamed package and since the language spec explicitly allows implementations to have different rules about whether and how classes in unnamed packages are visible to each other, it's generally a good idea to put all classes in named packages except for experimental code.

Where did you find that? Not quite sure what it means. All top‑level classes in an unnamed package have package‑private (=default) access or public access, so they are all visible to one another. Of course you can have a different unnamed package in a different folder, whose classes are not observable to the other unnamed package. I do not know whether you can change the classpath to make those classes observable.

[Jeff Verdegan]

Campbell Ritchie wrote:Of course you can have a different unnamed package in a different folder, whose classes are not observable to the other unnamed package.

I would be surprised if that's the case. For packaged classes, the ClassLoader just looks at the package--that is, where it is under the particular classpath root where it lives. It doesn't look at which classpath root it came from. package a.b.c is package a.b.c even if some of its classes came from X/a/b/c and some came from Y/a/b/c. I wouldn't expect things would be any different for unnamed-package classes living under X/ vs. Y/.

[Campbell Ritchie]

mkdir pack1
[campbell@localhost java]$ mkdir pack2
[campbell@localhost java]$ gedit pack1/Foo.java pack2/Bar.java
[campbell@localhost java]$ javac pack2/Bar.java
pack2/Bar.java:3: error: cannot find symbol
Foo f = new Foo();
^
symbol: class Foo
location: class Bar
pack2/Bar.java:3: error: cannot find symbol
Foo f = new Foo();
^
symbol: class Foo
location: class Bar
2 errors

The unnamed package inside pack2 folder appears not to be able to “see” the unnamed package in the pack1 folder.

Earlier, I wrote:I do not know whether you can change the classpath to make those classes observable.

If you add pack1 to the classpath

[campbell@localhost java]$ javac -cp pack1:. pack2/Bar.java

… it compiles first time. So you appear to be correct, Jeff, and I was mistaken.

[Jeff Verdegan]

Thanks for taking the effort to confirm that, Campbell. I like it when things are orderly and make sense.