Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Apparent Hierarchies of Packages

Tags:

java

packages

In this post http://java.sun.com/docs/books/tutorial/java/package/usepkgs.html

into the paragraph "Apparent Hierarchies of Packages" is written:

"" At first, packages appear to be hierarchical, but they are not. For example, the Java API includes a java.awt package, a java.awt.color package, a java.awt.font package, and many others that begin with java.awt. However, the java.awt.color package, the java.awt.font package, and other java.awt.xxxx packages are not included in the java.awt package. ""

but if I unjar rt.jar I discover that java.awt.color and java.awt.font are mapped in a hierarchical way: java/awt/color and java/awt/font so do I understand bad or in that post is there an error?

However is it possible to create not hierarchical packages? logical packages names that don't match a phisical packages structure?

like image 874
xdevel2000 Avatar asked Nov 19 '09 15:11

xdevel2000


2 Answers

The article you reference explains the point in the next paragraph. The names of the packages are used to indicate relationships to programmers' eyes but do not have any relationship in the eye of the compiler. As the article explains importing java.awt.* will not import any classes in java.awt.font they are completely separate packages that do not have any hierarchical relationship in the programming language. To import all the classes in java.awt.font you have to import java.awt.font.* and that does not import any classes in the parent package java.awt or in sibling packages like java.awt.color.

So even though there is an apparent hierarchical relationship to the programmer there really isn't any in the language. To access classes in a given package you have to import them from their exact package.

If packages were actually hierarchies then one might imagine that this would be the case. However the hierarchy is only there to organise the code and give hint to programmers that a given set of packages are intended to be used together.

like image 167
Tendayi Mawushe Avatar answered Sep 24 '22 16:09

Tendayi Mawushe


The article continues

Importing java.awt.* imports all of the types in the java.awt package, but it does not import java.awt.color, java.awt.font, or any other java.awt.xxxx packages.

So it just describes the general behaviour of the import statement: import package.* imports all classes from package but no classes from sub packages.

Yes, the class files are in rt.jar just where we expect them, this is only about importing classes in java source files.

Edit

Yes, the tutorial it adds a certain degree of confusion.

Try to understand a package as a collection of classes that share a common namespace. java.awt is a namespace, java.lang and java.awt.color is another one. And now understand, that the java.awt and the java.awt.color namespaces are not related. java.awt.color is not a 'child' namespace of java.awt. And indeed, there is no rule in Java that you have to put certain classes in certain 'child' packages. If there was a hierarchie, I'd expect some rules like implementations have to be declared in a 'child namespace' of the interface, or so. But there aren't any

Yes, the actual mapping for namespaces to filesystems introduces a folder hierachie, where color is a folder inside awt. That's pretty practical, otherwise we'd need a mapping between package namespace and physical location of the classes in the filesystem. Now we can determine the location from the package namespace. And that leads to the impression, that this hierarchie is true for the package namespaces as well.

But this is not the case. And that's what the tutorial wants to say.

(thanks for the question, I learned and understood a lot while thinking of the answer ;) )

like image 35
Andreas Dolk Avatar answered Sep 24 '22 16:09

Andreas Dolk