Java Reference
In-Depth Information
ERROR-PRONE CLASS PATH CONCEPT
The Java platform also inhibits good modularity practices. The main culprit is the Java
class path. Why does the class path pose problems for modularity? Largely due to all
the issues it hides, such as code versions, dependencies, and consistency. Applications
are generally composed of various versions of libraries and components. The class
path pays no attention to code versions—it returns the first version it finds. Even if it
did pay attention, there is no way to explicitly specify dependencies. The process of
setting up your class path is largely trial and error; you just keep adding libraries until
the
VM
stops complaining about missing classes.
Figure 1.2 shows the sort of “class path hell” often found when more than one
JAR
file provides a given set of classes. Even though each
JAR
file may have been compiled
to work as a unit, when they're merged at execution time, the Java class path pays no
attention to the logical partitioning of the components. This tends to lead to hard-to-
predict errors, such as
NoSuchMethodError
, when a class from one
JAR
file interacts
with an incompatible class version from another.
Merged class path
A
B
F
D
JAR 1
JAR 2
JAR 3
A
B
C
D
E
F
Figure 1.2
Multiple JARs containing overlapping classes and/or packages are merged based on their
order of appearance in the class path, with no regard to logical coherency among archives.
In large applications created from independently developed components, it isn't
uncommon to have dependencies on different versions of the same component,
such as logging or
XML
parsing mechanisms. The class path forces you to choose one
version in such situations, which may not always be possible. Worse, if you have multi-
ple versions of the same package on the class path, either on purpose or accidentally,
they're treated as split packages by Java and are implicitly merged based on order
of appearance.
Overall, the class path approach lacks any form of consistency checking. You get
whatever classes have been made available by the system administrator, which is likely
only an approximation of what the developer expected.
LIMITED DEPLOYMENT AND MANAGEMENT SUPPORT
Java also lacks support when it comes to deploying and managing your application.
There is no easy way in Java to deploy the proper transitive set of versioned code
dependencies and execute your application. The same is true for evolving your appli-
cation and its components after deployment.
