Java Reference
In-Depth Information
com.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
