Programmers are an organized bunch when it comes to writing code. They like to arrange their programs so that they flow in a logical way, calling separate blocks of code that each has a particular job. Organizing the classes they write is done by creating packages.
What Packages Are
A package allows a developer to group classes (and interfaces) together. These classes will all be related in some way - they might all be to do with a specific application or perform a specific set of tasks. For example, the Java API is full of packages. One of them is the javax.xml package. It and its sub packages contain all the classes in the Java API to do with handling XML.
Defining a Package
To group classes into a package, each class must have a package statement defined at the top of its .java file. It lets the compiler know which package the class belongs to and must be the first line of code. For example, imagine you're making a simple Battleships game. It makes sense to put all the classes needed in a package called battleships:
Every class with the above package statement at the top will now be part of the Battleships package.
Typically packages are stored in a corresponding directory on the filesystem but it is possible to store them in a database. The directory on the filesystem must have the same name as the package.
It's where all the classes belonging to that package are stored. For example, if the battleships package contains the classes GameBoard, Ship, ClientGUI then there will be files called GameBoard.java, Ship.java and ClientGUI.java stored in a directory call battleships.
Creating a Hierarchy
Organizing classes doesn't have to be at just one level. Every package can have as many sub packages as needed. To distinguish the package and subpackage a "." is placed in-between the package names.
For example, the name of the javax.xml package shows that XML is a sub package of the javax package. It doesn't stop there, under XML there are 11 sub packages: bind, crypto, datatype, namespace, parsers, soap, stream, transform, validation, ws, and XPath.
The directories on the file system must match the package hierarchy. For example, the classes in the javax.xml.crypto package will live in a directory structure of… javaxxmlcrypto.
It should be noted that the hierarchy created is not recognized by the compiler. The names of the packages and sub-packages show the relationship that the classes they contain have with each other.
But, as far as the compiler is concerned each package is a distinct set of classes. It does not view a class in a subpackage as being part of its parent package. This distinction becomes more apparent when it comes to using packages.
There is a standard naming convention for packages. Names should be in lowercase. With small projects that only have a few packages the names are typically simple (but meaningful!) names:
In software companies and large projects, where the packages might be imported into other classes, the names need to be distinctive. If two different packages contain a class with the same name it's important that there can be no naming conflict. This is done by ensuring the package names are different by starting the package name with the company domain, before being split into layers or features: