Java Reference
In-Depth Information
the second directory (this means that the files will be stored in the directories c:\dev\Proj\
classes\sampleproject\db\ and c:\dev\Proj\classes\sampleproject\testclient\ ,
respectively).
Next, both directories are compressed into separate JAR files using the JAR utility, as
shown here:
C:\devProj\classes\> jar cf db.jar sampleproject.db
C:\devProj\classes\> jar cf testclient.jar sampleproject.testclient
Finally, both JAR files are specified in a classpath when compiling a Java application, as
shown here:
C:\devProj\tmp\> javac -cp c:\devProj\classes\db.jar;c:\tempClasses\testclient.jar
MyClass.java
The question at this point is, what happens to the classpaths? Does the first JAR file over-
write the package path of the second file? The answer is no. Packages with the same package
tree can be stored in separate JAR files or separate directories, and in this case, the Java com-
piler will combine the contents of these two files at runtime.
Caution If you have classes with the same name that are in the same package namespace in two JAR
files, the first one found (based on classpath order) will be used—the second will be ignored.
The ability to store package definitions in different locations allows for a very modular
structure. Thus, you should consider certain ideals when planning an application's package
structure. First and foremost, packages should consist of all classes that are similar in function
or are dependent on each other in design. This allows for the packages to function as com-
plete units of functionality. Thus, a JAR file could conceivably contain an entire functional
package that is “plugged” into a project.
Note The sample project introduced later in this topic uses package structure to isolate the different net-
work implementations. This structure enables the entire networking layer of the sample application to be
changed without impacting the application's other packages.
Classes in the base node of every package should be the building blocks of that tree's
functionality, and therefore they should be the most stable portions of the tree. Lower-level
packages designate the stable classes that all others are built upon, and package definitions
should be planned using this principle.
If it is not possible to place only stable, nonchanging classes in the base nodes of a pack-
age, the classes should be replaced by interfaces, and the volatile implementations of these
interfaces moved to a higher level of the package definition or into a whole different package
altogether.
Search WWH ::




Custom Search