What is a package?
In Java, classes and interfaces are organized into packages. Packages are very similar in concept to directories or folders—and in fact, packages are implemented as directories in the underlying filesystem.
Packages are not only useful to aid in the physical organization of our Java source code, and the output produced by the compiler (the bytecode); they also provide establish namespaces. For example, two classes can have the same name, but as long as they are in different packages, the Java compiler and the Java class loader (part of the Java Runtime Enviroment, or JRE) can distinguish between them easily. In fact, those two classes actually have different names: the fully-qualified name of a class includes its package, as well as its simple name.
Package names may contain only alphanumeric characters and the underscore (_). Conventionally, they are written entirely in lowercase. In some style guides, if a package name consists of multiple words, the underscore is used as a separator. However, in the Java style guide used in the Deep Dive Coding Java + Android Bootcamp, and in the Google Style Guide that the DDC style guide is based on, underscores are never used in package names, and the lowercase convention is strictly followed, with no exceptions.
Packages, like directories, can be (and usually are) hierarchical. However, where Windows uses the backslash character (\) between the directories in a hierarchical directory specification, and *nix platforms use a forward slash (/), Java uses a dot or period (.). For example, we may define the package name com.mycompany.dev; this means that there is a package named com, which contains within it a subpackage named mycompany, which contains in turn a subpackage named dev.
As discussed in “JRE & JDK: Java Class Library (JCL)”, the Java standard library (aka the “Java Class Library”, or JCL) is organized in a hierarchical fashion: at the root level, the core standard library defines the java package, and there are several subpackages within that package—e.g. lang, util, io, net, etc. Many of those subpackages contains subpackages as well. There’s also a second “tree” of packages in the standard library, starting with javax, used for high-level extensions to the facilities in the java package (and its subpackages); javax contains subpackages such as crypto, swing, xml, etc.
Outside of the standard library, the most widely followed convention for package hierarchies is that a given development organization names its packages (at least, at the top levels of the package hierarchy) using the reverse of the organization’s domain name. For example, the package structure for Java code written by developers at IBM will typically start with com.ibm—that is, starting with a package named com, then a subpackage named ibm inside that, with additional subpackages (as needed) inside that.
Deep Dive Coding is part of CNM Ingenuity, which is itself a division of CNM. Thus, the package structure we will use in our exercises, projects, and practical exam problems will always start with edu.cnm.deepdive. (Alternatively, we could have opted to use CNM Ingenuity’s own domain, and chosen org.cnmingenuity.deepdive as our base package—but that’s a bit longer to type, and more error-prone to spell.)
Within the edu.cnm.deepdive package, we will often define additional subpackages. In particular, our Android and Spring Boot projects will define a project-level subpackage (Spring Boot is a framework we’ll use when building server- or cloud-based applications). For example, one project we’ll build is called “Codebreaker”; the base package for that project will be edu.cnm.deepdive.codebreaker, and all the code we write for that project will be within that package and its subpackages.
As noted in the overview (above), packages are tied to directory structures: a subpackage within another package corresponds to a subdirectory within a directory. For example, if we create a class named Generator in the edu.cnm.deepdive.codebreaker package (mentioned above), the Java source code for that class will be in a file called Generator.java, and it will be located in the following directory structure:
edu
cnm
deepdive
codebreaker
Generator.javaAs also noted above, the Generator class in this example is more correctly referred to by its fully-qualified name, edu.cnm.deepdive.codebreaker.Generator. Fortunately, as we’ll discuss in “Imports” we don’t have to use the fully-qualified class name too often.