Packages - Java: The Good Parts - page 51

Just to remind you, if you have a class that begins with the line:
package com.oreilly.javaGoodParts.examples.impl;
then the source for that class will need to be in a directory (from wherever you start) with the
name (on an adult operating system):
com/oreilly/javaGoodParts/examples/impl
that is, in the impl directory placed in the examples directory placed in the javaGoodParts
directory placed in the oreilly directory placed in the com directory. At the lower level of the
package naming hierarchy, this doesn't seem all that unnatural. You have different directory
locations for the files that implement a related part of the system, and those parts reflect the
package structure. Even at some of the higher levels this seems to make some sense; as a peer
to our examples, we will have the tests for those examples, clustered in their own namespace
and in their own directory.
At the next level, things get a little less sensible. I may be doing multiple topics for O'Reilly,
but this doesn't seem to be something that should be reflected in the filesystem on my com-
puter. Sure, I'll keep the different topics in different directories, but I might not want them to
share a parent directory. And at the highest level, this just seems odd. I may be doing work for
organizations that appear in different DNS domains on the Internet, but this hardly seems like
a reasonable way to organize my local files.
This is where we get to see the wisdom of the adage “History clarifies stupidity.” [ 13 ] What is
meant by this adage is that if you understand the history of some set of decisions, you can
often see why they seemed like a good idea at the time. This is the best way to understand the
tie between Java packages and the filesystem.
When Java was first being implemented, there were many projects within Sun (and, no doubt,
elsewhere) that were trying to build a programming environment in which the source and bin-
ary files would be kept in a database. There were lots of reasons why this would have been a
good idea: it would have helped with incorporating a version control system, releases could
be done more consistently, and queries over the structures held in the database could help pro-
grammers understand the structure of the system. The Java packaging system would have fit
into such an environment beautifully. The unique names would act as primary keys, and the
hierarchical nature of the names would map naturally into all kinds of database structures.