CHAPTER 2 ■ JAVA SYNTAXcom.bryantcs prevents the troubles that arise from having two packages with the same name. By
convention, this part of the package name is done in reverse, because the domain name is more specific
than the domain category name, and package names should work from less specific on the left to more
specific on the right. Thus, when reading from left to right, we get the domain category (com), the domain
(bryantcs), the kind of application (examples), and finally the name of the innermost package
(syntaxExample). The first two (com.bryantcs) are part of the standard Java naming convention. The last
two (examples.syntaxExample) are just our own convention for keeping the programs from getting
tangled up with one another.
Here's another example of a package declaration:
org.apache.fop
That refers to the FOP (Formatting Objects Processor) project at apache.org. (Apache is a leading
provider of open-source software and a great place to get involved as a Java developer or tester.)
Package names can be much longer, because they grow to indicate packages within packages
(within packages, and so on). Here's a longer example from the FOP project:
org.apache.fop.fo.pagination.bookmarks
That one refers to the bookmarks package, which is within the pagination package, which is within
the fo package, which is within the fop package. Packages nested several levels deep is a common
practice in commercial projects. Few useful applications can reasonably fit into just one package.
You can include code from other people's projects (and your own existing projects) by including the
package in which the code you want used resides. This mechanism enables developers to share code and
lets one company write (and charge money for) code that other companies use.
Imports
After the package declaration, we get the import section (shown in Listing 2-3, earlier in this chapter).
Any number of import statements can be present.
An import statement says your class uses one or more classes or interfaces from another package.
That way, you can write two entirely separate applications but share code between them. Also, someone
else can write a library that you can then use by importing the parts of the library you want to use.
Let's examine our import statements in Listing 2-7:
Listing 2-7. Import statements
import java.text.SimpleDateFormat;
import java.util.Date;
After the import keyword, we get a class identifier. Again, it pays to read from right to left when
making sense of a class identifier. java.text.SimpleDateFormat says the SimpleDateFormat is within the
util package, which is within the java package.
That particular class is from the official Java library. This import statement tells experienced Java
developers that AverageTest is going to format a date.
Now, suppose we want to use other classes within the same package. We can then use a wildcard
character (*) to specify any class within the package, thus:
import java.text.*;
Every different development shop has a different standard for when to stop being specific and use
the wildcard. We prefer to use the wildcard when we have three classes or interfaces from the same