Java Reference
In-Depth Information
THE PROBLEM WITH EARS
Although they add a different level of granularity to Java,
EAR
s don't do much to help
with Java modularity.
EAR
s have no practical way to declare dependencies except to
package all their required
JAR
s inside themselves. This leads to big
EAR
s! Carrying all
your dependencies around with you is a blunt mechanism for dependency manage-
ment, and it can cause considerable bloat at runtime. An application server can end
up hosting many redundant copies of common libraries, one for each application.
A Java
EE
application server represents a large investment of money and comput-
ing resources, so they're typically used to run a number of applications. As you can see
from figure 4.1, when two applications make use of the same library, which happens
quite a lot, they end up running side by side. In the worst cases, the modules within an
EAR
will also package duplicate libraries, and without careful management when pack-
aging this can lead to considerable bloat.
Some application servers have added extensions to allow libraries to be shared
between Java
EE
applications, but these extensions are unique to each vendor.
EAR
s
with shared library dependencies are therefore necessarily less portable than their
bulkier self-contained equivalents. Installing such an
EAR
involves an extra set of ven-
dor-specific installation steps. (“Make sure there is a copy of something.jar in lib,
unless you're on this other application server, in which case it's the ext folder it needs
to be copied to.”) Added to this complexity, there's no way of knowing what the
shared dependencies of an
EAR
are except through documentation. If the documen-
tation is incomplete or missing, the application will probably deploy without error
only to fail with an unpleasant
ClassNotFoundException
at runtime. Some missing
dependencies might not be discovered until well into production.
Even if all the shared dependencies of an
EAR
are identified and installed, success
isn't guaranteed. What happens when different applications on the same server
library3.jar
library4.jar
library2.jar
library2.jar
library1.jar
library1.jar
kitchensink.jar
kitchensink.jar
app1.ear
app2.ear
Figure 4.1
Duplication of common libraries between EARs
