Packages - Java: The Good Parts - page 43

you know that the code in the file is in the bar package, which is part of the foo package,
which is part of the sun package, which is part of the com package.
The basic function of a package is to create a namespace. All of the names that are externally
visible in a source file are scoped to that package. A name that occurs in one package can
appear in a different package, and the two names will be seen as distinct. This by itself gives
an independence of structure to what you are doing; as long as you are working in a differ-
ent package (and namespace) than the one I am working in, we don't have to coordinate the
names that we use if our work is going to be used together.
Because having separate namespaces is important, it also is important that the names of the
packages themselves be different. Java is a name-equivalence language and environment,
which means that things with the same name are the same. Thus, if I have two classes with
exactly the same name but very different implementations, Java won't tell them apart; which
one actually gets used will depend on the order in which the class files are encountered. Once
some class with a name is loaded, any class with that same name will use the loaded imple-
mentation. [ 12 ] Making sure that your package names are unique lets you avoid unintentionally
introducing a name that is the same as one introduced by someone else.
Of course, generating a unique name is not as easy as it sounds, especially if you are building
some code that might be used by others at some time in the future and at some as-yet unknown
place. This is really an instance of the general problem of generating unique identifiers in a
distributed system (with you and all of the other programmers who use Java as nodes in the
distributed system), made somewhat more complex by the lack of good connectivity between
the nodes (programmers) in this particular system and the fact that the nodes are all pro-
grammed to behave in various nondeterministic ways (or, if deterministic, using an algorithm
that is currently unknown). All of which is geek-speak for saying that you never know what
people are going to do, and there is no way to find out until it is too late.
To help ensure that package names are in fact unique, a convention was started early in the
history of Java development that a package name should start with the domain name (in re-
verse order) of the organization from which the package originates. Thus, packages that ori-
ginate from Sun Microsystems, Inc. start with the prefix com.sun , those from Hewlett Pack-
ard, com.hp , and those from Harvard University, edu.harvard . It is up to the organization to
figure out how to generate unique names, but this is a more local problem (although for these
organizations, no less complex). Finally, there are some package names that are reserved for
the system itself; these include the java and javax names.
Of course, there are times when I'm not writing code for any particular organization but just
hacking on my own. I could, in those cases, use the same prefix as I would if I were writing for