Unwrap the package statement's potential

Minimize project complexity and maximize code reuse

By Laurence Vanhelsuwé, JavaWorld.com, 02/21/03

Apart from the well-known and generally observed Sun Microsystems package naming convention for avoiding top-level package name collisions, few programmers thoroughly understand the deceptively simple package statement. Most Java programmers think the package keyword is little more than a broadaxe means to group project classes together. Most Java programmers simply use the package feature to create one unique namespace per project. Unfortunately, this approach does not stand the test of time nor scale.

When a simplistic packaging attitude scales up to team-scale (let alone enterprise-scale) Java code repositories, it gradually and painfully becomes clear that incorrectly creating and managing your Java code repository's package hierarchy can have costly and profound code maintenance implications. Worse still, these problems grow as your codebase matures and typically infect code with total disregard for project boundaries.

Consequently, when it comes to using the package statement, a few decisions must be made correctly from day one.

In this article, I explain why many Java programmers improperly use the package keyword and show you one alternative approach that has stood the test of time.

The newbie approach of using Java packages

When you first started programming in Java, you typically did not use the package statement at all. The classic HelloWorld introduction to the language quite rightly does not use nor discuss Java packages or its package keyword in any way:

// (No package statement here!)
class HelloWorld {
   public static void main(String[] args) {
      System.out.println("Hello World");
   }
}

You simply declared your classes implicitly in the default package (the package with no name) so you could run your Java program in the least verbose way (i.e., by commanding your console):

> java HelloWorld

Luckily, Java's design wasn't crippled by this program execution convenience. Elegantly and powerfully supporting large-scale programming projects was one of the top design priorities, and this is reflected in the package language feature. Hence, the newbie approach of class declaration in the default package is not sustainable when you graduate to implementing real projects.

Class name collisions and the birth of packages

As you get more comfortable with Java, you quickly find that leaving all of your project's classes in the default package limits the practical number of classes this default package namespace can hold. For example, if your first few experimental classes were called Main or Program, and your first true project also required a Main or Program class as its main entry point, then you would have a class name collision. Either you deleted your old classes or you remembered that Java allows you to create multiple package namespaces by subdividing the global namespace into multiple package-scope spaces.

The point at which Java newcomers typically and finally see the light in regards to the package statement is when they start their second Java project and want a clean separation between their first project's classes and their second project's classes.