Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Packages
Java packages have an interesting nesting property. Packages can be nested within one another, but the language grants no special privileges to packages that are so nested. There is no special connection between javax.swing, javax.swing.text, and javax.swing.text.html, at least as far as the implementations are concerned. If you renamed the packages to swing, swing_text, and swing_text_html, so that all three packages existed at the same level, the code would compile and nothing would change.
There is one technical reason to organize code that way. When there are dependencies between packages, it's convenient to make one package a sub-package of the other. Then the compiled code can be picked up and moved as a single unit, because they all exist in a single directory. Some programmers also arrange their source code that way, which affords the same benefit to the source. I prefer to have my source code exist in larger chunks, with a collection of related packages all in the same directory. That way I don't have to remember that the Server class resides in the com/foobar/server directory, while one database implementation lives in the com/foobar/server/database and the disk implementation in com/foobar/server/disk. I can find it just with the name of the class.
There's also a software maintenance reason to organize packages in a nested fashion, and the maintenance programmer can take advantage of that. Intuitively, the higher packages tend to be more abstract, and the lower packages more concrete. In my example above, if you needed to maintain this code and you wanted to know what a Server did, you'd rather look at com.foobar.server.Server rather than com.foobar.database.DatabaseServer. The latter is cluttered with implementation details, while the former is more likely to explain what's going on. When exploring a new code base, you should generally start with the upper packages and work your way down, breadth-first.
In the organization of the standard Java packages, Sun made a deliberate choice to put the portable look-and-feel classes in a package with the slightly forbidding name of plaf. The idea was to keep you from poking around inside it until you had to, and most programmers will never look inside those classes. Sun wanted to make them public, so that programmers could add their own look-and-feel implementations, but to hide them just enough that they wouldn't want to poke around until they were ready.
The depth argument only goes so far here; the javax.swing.plaf package is brother to javax.swing.table, which many programmers do go into. But they only start exploring javax.swing.table after they've explored the classes in javax.swing and discovered that the basic default table models and cell renderers provided there don't suffice.
When looking around in a package, start by assuming that all of the classes there are organized at the same level of "visibility." That is, if one class in a package is intended for public consumption, they all probably are, at least for the publicly visible classes. So when you've located the package containing an object of interest, scan all of the other classnames just to get a feel for the way the class of interest may interact with the other classes around it. Then you can set about trying to figure out how to create an instance of your class of interest.
Another clue: Often, the most important class in a package will have the same name as the package itself, or something similar. For example, in the Thorn project, the main executable is in the class thorn.Thorn. The server in my example above is com.foobar.server.Server. It may seem repetitive to do it that way, and it is: The name of the main package is the name of your project, and the name of the main class in the main package is also the name of the project. The alternative is to be too generic, such as the main class of SimplyHTML, which is com.lightdev.app.shtm.App. App is pretty generic, but it gets the point across: It's the application for the shtm package.