Java Reference
In-Depth Information
although there's a distinct object structure (the chunks of vegetable and pasta), there's
no structure beyond the individual objects. The objects are thrown together in a soup
and every vegetable can see every other vegetable.
CLASSPATH HELL
Insufficient encapsulation isn't the only problem with Java's existing modularity. Few
Java
JAR
s are entirely freestanding; most will have dependencies on some other librar-
ies or frameworks. Unfortunately, determining what these dependencies are is often a
matter of trial and error. Inevitably, some dependencies may get left off the classpath
when it's run. In the best case, this omission will be discovered early when a
ClassNot-
FoundException
is thrown. In the worst case, the code path will be rarely traveled and
the problem won't be discovered until weeks later when a
ClassNotFoundException
interrupts some particularly business-critical operation. Good documentation of
dependencies can help here, but the only reliable way of ensuring every dependency
is present is to package them all up in a single archive with the original
JAR
. This is
inefficient and it's extra frustrating to have to do it for common dependencies.
What's worse, even packaging
JAR
s with all the other
JAR
s they depend on isn't
guaranteed to make running an application a happy experience. What if a depen-
dency is one of the common ones—so common that other applications running in the
same
JVM
(Java Virtual Machine) depend on it? This is fine, as long as the required
versions are the same. One copy will come first on the classpath and be loaded, and
the other copy will be ignored. What happens when the required versions are differ-
ent? One copy will still be loaded, and the other will still be ignored. One application
will run with the version it expects, and the other won't. In some cases, the “losing”
application may terminate with a
NoSuchMethodError
because it invokes methods that
no longer exist. In other, worse cases, there will be no obvious exceptions but the
application won't behave correctly. These issues are incredibly unpleasant and in Java
have been given the rather self-explanatory name
classpath hell
.
Although classpath hell is a bad problem in core Java, it's even more pernicious in
the enterprise Java domain.
1.1.2
Enterprise Java and modularity—even worse!
Enterprise Java and the Java
EE
programming model are used by a large number of
developers; however, there are many Java developers who have no experience with
either. Before we can explain why enterprise Java suffers even more greatly than stan-
dard Java, we need to make sure that we have a common understanding of what the
enterprise is.
WHAT DISTINGUISHES ENTERPRISE JAVA FROM NORMAL EVERYDAY JAVA?
Part of the distinction is the involvement of the enterprise—enterprise Java is used to
produce applications used by businesses. But then businesses use many other applica-
tions, like word processors and spreadsheets. You certainly wouldn't say that a word pro-
cessor, no matter how business-oriented, had been produced to an enterprise
