Explicit package hierarchies

Question

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

in the section "Explicit package hierarchies" it says:

“At first, the packages look hierarchical, but they don’t. For example, the Java API includes the java.awt package, the java.awt.color package, the java.awt.font package, and many others that start with java.awt. However, the java.awt package .color, 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 find that java.awt.color and java.awt.font are displayed in a hierarchical path: java / awt / color and java / awt / font, so I don’t understand well or there is a message in this message error?

However, is it possible to create non-hierarchical packages? names of logical packets that do not match the structure of phase packets?

Answer 1

The article you are referencing explains the point in the next paragraph. Package names are used to indicate relationships with the eyes of programmers, but are not related to the compiler eye. The article explains that importing java.awt.* Will not import any classes in java.awt.font , they are completely separate packages that do not have any hierarchical relationships in the programming language. To import all classes in java.awt.font , you need to import java.awt.font.* And not import any classes into the parent java.awt or into sibling packages such as java.awt.color .

Thus, despite the obvious hierarchical attitude towards the programmer, in fact this does not exist. To access the classes in this package, you must import them from your exact package.

If the packages were actually hierarchies, then one could assume that this would be so. However, the hierarchy exists only in order to organize the code and give a hint to programmers that this set of packages is intended for sharing.

Answer 2

Article continues

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

Therefore, it simply describes the general behavior of the import statement: import package.* Imports all classes from package , but does not contain classes from subpackages.

Yes, class files are located in rt.jar only where we expect them, it is only about importing classes into java source files.

Edit

Yes, the textbook adds a certain degree of confusion.

Try to understand a package as a collection of classes that have a common namespace. java.awt is the namespace, java.lang and java.awt.color are different. And now understand that the java.awt and java.awt.color namespaces are not related. java.awt.color not a "child" java.awt namespace. Indeed, there is no rule in Java that you must put certain classes in specific "child" packages. If there was a hierarchy, I would expect some rules, such as implementations, to be declared in the "child namespace" of the interface or so. But there are no

Yes, the actual namespace mapping on file systems is the hierachie folder, where color is the folder inside awt. This is pretty practical, otherwise we need a mapping between the package namespace and the physical location of the classes in the file system. Now we can determine the location from the package namespace. And this leads to the fact that this hierarchy is also true for package namespaces.

But this is not so. And what the textbook wants to say.

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

Answer 3

What the tutorial means is that Java has no concept of subpackages. A package may be physically located in a subfolder of the file system, but this does not mean that it will be automatically included (see Andreas answer ).

It also does not give classes in higher-level package rights access to classes with private access (by default), as one would expect if there was a package hierarchy.

Answer 4

Naming scheme hierarchical as well as the contents of jar files.

However, there is no connection between java.awt and java.awt.color, that is, if you declare the class as private (without modifiers) in the foo package, it will be available from foo, but not from foo.bar.

Answer 5

Think of a hierarchy as a file system. In Java, packages are like directories, and classes are like files. Packages are designed to host a set of related classes. When there are groups of packages that are logically related to each other, they can be called so that they appear as members of a larger hierarchy. Looking at the java.awt example above. *, I could put classes for AWT in jar1. It will have the following structure:

 jar-1 \-java \-awt 

In the awt directory, you will find classes and interfaces that declare themselves members of the java.awt package.

Now I want to implement some fonts for awt, but I put them in a separate jar:

 jar-2 \-java \-awt \-fonts 

The font catalog are the classes and interfaces for fonts that I created for awt.

When you switch to a program using AWT and my fonts, you must first include both jar-1 and jar-2 in your CLASSPATH. When you include classes, you will not get any information about what jar the compiler found in them.

 //this loads all classes in the java.awt directory // which happen to come from jar-1 include java.awt.* 

If you want to use fonts,

 //Load all classes in the java.awt.fonts directory // which happen to come from jar-2 include java.awt.fonts.* 

For the compiler and runtime, the hierarchy looks like one big tree. This does not mean that all classes are physically in the same place. Having said that I have to make two points; 1) Separating packages in the same hierarchy into different banks is not recommended, as this will confuse and support a headache, and 2) declaring packages as extensions of some other package structure is an extremely bad form, even if the compiler allows it .