File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes basic package/class visibility question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "basic package/class visibility question" Watch "basic package/class visibility question" New topic
Author

basic package/class visibility question

Joe Boman
Greenhorn

Joined: Dec 10, 2009
Posts: 20
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.



Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39385
    
  28
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
Greenhorn

Joined: Dec 10, 2009
Posts: 20
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Sheriff

Joined: Oct 13, 2005
Posts: 39385
    
  28
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Greenhorn

Joined: Dec 10, 2009
Posts: 20
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
Sheriff

Joined: Oct 13, 2005
Posts: 39385
    
  28
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Sheriff

Joined: Oct 13, 2005
Posts: 39385
    
  28
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Thanks for taking the effort to confirm that, Campbell. I like it when things are orderly and make sense.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: basic package/class visibility question