The Tank Software Guide to Good Java Programming
Part II - Packages
Section 1: Packages
Packages are an integral part of the Java language, and are another reason why it so powerfull.
You use packages all the time. For example: the line import java.util.*; gives you access to all classes in the "java.util" package. importing "java.util.List" gives you access to the List class. Alternativly, private java.util.List blab = new java.util.List (); is also a way to use them (recommended really when you only use it once or twice, any more and you probably should use an import statement.
Why should you make your classes into packages?
There are several reasons, firstly it makes your code easier to understand,
as intuitivly, a "io" package will contain Input/Output classes. You
save on the "namespace" which means you can use the same class name twice
(provided it is in a different package) although doing that isn't recommened.
By default all of your classes are in the "default" package, or unammed
package, which can lead to conflicts if someone wants to use one of your classes
that is named the same with theirs. But probably the biggest is it
make code-reuse much easier. I shall use my own case as an example.
Before using packages, I had made 2 classes which almost all of my programms
used. One was named "Delegate" and contained some handy methods that
I used a lot, and the other was my custom about dialog box. What I
did is I had a copy of the files in all of my projects. The problem
with this was I had to keep track of which one was the most up to date, and
only make changes to that, and copy it into several different directories
each time I did. With packages as you will see later, you simply set
the package path in your java classpath, and all of your applications can
use the same classes, reducing redundecy.
How to create packages:
It is really very easy, just follow these steps:
1. at the TOP of your .java files eg "AJavaSource.java", before any
other statemnets (comments are of course ok) put the line:
"package com.company.apackage;"
2. Place this .java file in a directory "/somedirectory/com/somecompany/apackage/AJavaSource.java".
That directory can be anywhere, but it MUST have that structure.
Then delete your old .class files (somthing you should always do when renaming .java/changing stuff like that) and re-compile.
How to use packages:
Just like java.util, use them as described above (eg "import com.somecompany.apackage.*;)
in your .java files. And you must make sure that the directory containing
the package is in your classpath! For example, if the above file AJavaSource.java
was executable (ie has a main method) then this is how you could run it, lets
say you are in the direcory "/home/adirectory" which has the sub-directory
"somedirectory" containing your package, this is what you would do
"java -cp "somedirectory" com.company.apackage.AJavaSource".
or if you are executing a .class file eg "Test.class" with
a main method in the directory "/home/adirectory" which you are in, you could
use this:
"java -cp "somedirectory" Test
For a IDE envirment like JBuilder, simply set that directory up in the classpath, or as a library.
Another good point about packages is that the classes can be placed inside a single JAR file (see Guide III ) and that can be placed in your classpath instead of the directory.
Section 2: Naming Conventions
I have observed that the package names from several packages
from different sources use the following convention:
All packages that are included with the java sdk get the prefix "java" eg
"java.util" or "java.io"
All other packages use the following form "com.somecompany.apackage" where
"somecompany"is your company, and "apackage" is the package name. While
this is not enforced, it is highly recommended, as it improves code readibility
and understanding. I would also use only lowercase letters in the package
name, again not enforced. Whatever you do, DON'T start it with a capitol
letter (reserved for class names by normal standards, although again not enforced).
By William Denniss
Created 27 Apr 2002,
Modified 27 Apr 2002.