Java's Standard Packages

Java's standard library is organized into packages, and the names of those packages often look longer than they first appear. The package that provides the Scanner class, for instance, is not called util on its own. It is called java.util. Before you can read a package name correctly, you need to know how one package can sit inside another. This article traces names from the outside in, so that by the end you can read a name such as java.io and say exactly where it lives.

Keep one idea in mind as you read: a package name is a path, not a flat label. Each dot in the name marks one step further into the structure, and the name records the chain of containers from the outermost one down to the one you are looking at.

Take the name java.util. Reading from left to right, the leftmost part, java, is the outer package. The part after the dot, util, is a package that sits inside it. Reading the name from the inside outward would lose the relationship, so always read it from the outside in.

The same reading applies to java.io and java.net. Each has java on the left and a single additional segment on the right. In every case, the segment after the dot names a package that lives directly inside java. Neither name needs more than one dot, because each sits exactly one level below java in the structure.

The diagram above shows the reading order. Each dot moves you one step further into the containment chain. The Scanner class sits at the end of the name, after the package that holds it. The source's central point is that the dots record containment, so the name tells you where the package lives.

This is the central fact of the article, and it changes how you should think about a package. A package is a container, and its contents are not limited to classes. The same package might hold ordinary classes directly, and also hold other packages. Each contained package is a subpackage of the one that holds it.

The source gives two top-level packages as examples of this structure. The java package and the javax package both contain subpackages. The java package has many of them. The source names java.util, java.io, and java.net, and it states that java.util is a subpackage of java. The diagram below places java at the top and shows the subpackages the source names directly beneath it.

Read the diagram from top to bottom and it matches the naming rule. Each child box carries the label of its parent followed by a dot. The java.util box holds the utility classes, and the source connects it to the Scanner class. The java.io box provides facilities for input and output, and the java.net box deals with network communication. The diagram shows only what the source describes. The java package contains more subpackages than these four, and the javax package also contains subpackages of its own that the source does not list.

The source's own examples stay one level below java. The same method works at any depth, because the containment rule applies at every level. A subpackage can itself be a container for other packages. The procedure is always the same: start from the outermost package, then append each inner package with a dot.

Notice what the worked example reveals. The name java.util.sub has two dots, so it sits two levels below the top. The name java.io has one dot, so it sits one level below java. Counting the dots and reading left to right gives you the depth and the chain of containers at once.

The source calls java.lang the most basic package. It contains fundamental classes, and the source lists four of them: String, Math, Integer, and Double. Many other parts of Java programming rely on these classes, which is why the source singles this package out as the foundation.

Its name still follows the containment pattern. java.lang is written with java on the left, so it is one of the packages held inside java, alongside java.util, java.io, and java.net. Being the most basic package does not place it outside the hierarchy. It sits at the same level as its sibling packages and is distinguished by the classes it holds.

Several errors come up often when people first read package names. Each one usually comes from treating a package name as a flat label rather than as a path through containers.