- CourseSession
- Enrolling Students
- int
- Initialization
- Default Constructors
- Suites
- The SDK and java.util.ArrayList
- Adding Objects
- Incremental Refactoring
- Objects in Memory
- Packages and the import Statement
- The java.lang Package
- The Default Package and the package Statement
- The setUp Method
- More Refactoring
- Class Constants
- Dates
- Overloaded Constructors
- Deprecation Warnings
- Refactoring
- Creating Dates with Calendar
- Comments
- Javadoc Comments
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Default Package and the package Statement
None of the classes you have built—AllTests, StudentTest, Student, CourseSessionTest, and CourseSession—specify a package. This means that they go into something called the default package. The default package is fine for sample or academic programs. But for any real software development you do, all of your classes should belong to some package other than the default package. In fact, if you place classes in the default package, you will not be able to reference these classes from other packages.
If you are working in a modern IDE, moving a class into a package can be as easy as dragging the class name onto a package name. If you are not working in an IDE, setting up packages and understanding related classpath issues can be somewhat complex. Even if you are working in an IDE, it is important to understand the relationship between packages and the underlying file system directory structure.
Let's try moving your classes into a package named studentinfo. Note that package names are by convention comprised of lowercase letters. While you should still avoid abbreviations, package names can get unwieldy fairly quickly. The judicious use of abbreviations might help keep the package name from being unmanageable.
You should also not start your package names with java or javax, both of which should be used exclusively by Sun.
If your IDE supports moving classes into packages as a simple operation, go ahead and take advantage of it. However, make sure you understand how the classes relate to a package structure, as this will be important when you construct deployable libraries. Consider copying the source files into a different directory structure and following the exercise anyway.
From the directory in which your class files are located, create a new subdirectory called studentinfo. Case is important—ensure that you name this subdirectory using all lowercase letters. If your source files are currently located in c:\source, then you should now have a directory named c:\source\studentinfo. Starting with a Unix directory named /usr/src, you should have a directory named /usr/src/studentinfo.
First carefully delete all of the class files that have been generated. Class files, remember, end with a .class extension. Don't lose all of your hard work—back up your directory if you are unsure about this step. Under Windows, the command:
del *.class
will suffice. Under Unix, the equivalent command is:
rm *.class
After deleting the class files, move the five source files (AllTests.java, StudentTest.java, Student.java, CourseSessionTest.java, and CourseSesson.java) into the studentinfo directory. You need to store classes in a directory structure that corresponds to the package name.
Edit each of the five Java source files. Add a package statement to each that identifies the class as belonging to the studentinfo package. The package statement must be the very first statement within a Java class file.
package studentinfo;
class Student {
...
You should be able to compile the classes from within the studentinfo sub-directory.
However, two things will have to change when you run JUnit against AllTests. First, the full name of the class will have to be passed into the TestRunner, otherwise JUnit will not find it. Second, if you are in the studentinfo directory, the TestRunner will not be able to find studentinfo.AllTests. You must either go back to the parent directory or, better yet, alter the classpath to explicitly point to the parent directory. The following command shows the altered classpath and the fully qualified test class name.
java -cp c:\source;c:\junit3.8.1\junit.jar junit.awtui.TestRunner studentinfo.AllTests
In fact, if you explicitly point to c:\source in the classpath, you can be in any directory when you execute the java command. You will also want to use a similar classpath in javac compilations:
javac -classpath c:\source;c:\junit3.8.1\junit.jar studentinfo\*.java
Another way to look at this: The classpath specifies the starting, or "root," directory in which to find any classes that you will use. The class files must be located in the subdirectory of one of the roots that corresponds to the package name. For example, if the classpath is c:\source and you want to include the class com.mycompany.Bogus, then the file Bogus.class must appear in c:\source\com\mycompany.
A package-naming standard is something that your development team will want to agree upon. Most companies name their packages starting with the reverse of their web domain name. For example, software produced by a company named Minderbinder Enterprises might use package names starting with com.minderbinder.