OSGi and the enterprise—why now? - Enterprise OSGi in Action - page 21

UTILITY LIBRARIES AND OSGI
One of the big successes for Java has been that a large open source community has
grown around it, providing a cornucopia of libraries, frameworks, and utilities. These
libraries are so commonly used that there are almost no applications that don't use
any and most applications use several. Some libraries are so commonly used that many
developers consider them to be part of the Java API .
Many of these Java libraries were not originally written with OSG i in mind. This
means that they have to be manually converted into OSG i bundles by the developers
using them. The developers have to guess which packages are API and which package
dependencies exist, making the conversion process time consuming and error prone.
We think this is a key reason why OSG i is often perceived as difficult.
Unfortunately for developers new to OSG i, the problems with open source libraries
don't end with packaging. Many libraries require users to provide some configuration,
and sometimes implementations of classes. In standard Java, with its flat classpath,
these resources and classes can be loaded easily using the same classloader that loaded
the library class. In OSG i, these resources and classes are private to the application
bundle, and can't be loaded by the library at all! Problems like this are widespread in
libraries that weren't written with OSG i in mind and can't usually be solved without re-
engineering the library significantly.
Fortunately for OSG i, open source libraries are increasingly available with OSG i-
friendly packaging and API , meaning that OSG i is becoming easier to use than ever
before. This effort is being made not only by the open source community, but also in
new OSG i specifications, where the OSG i alliance is providing new, OSG i-aware mecha-
nisms to make use of existing technologies.

1.2.4 Why OSGi and Java EE don't work together

Unfortunately, utility libraries aren't the only barrier to OSG i adoption. Many Java
applications run on application servers, and use some form of enterprise Java, even if
it's only servlets or dependency injection. Sadly, the Java EE programming model has
historically been incompatible with OSG i. Enterprise Java exists because the Java com-
munity recognized common needs and practices across a variety of business applica-
tions. Java EE provides a common way to make use of enterprise services.
Unfortunately, Java EE aggravates the modularity problems present in standard Java,
and is more resistant to OSG i solutions.

FRAMEWORKS AND CLASS LOADING
Enterprise Java application servers are large beasts, and typically host multiple applica-
tions, each of which may contain many modules. In order to provide some level of iso-
lation between these applications, there's a strict classloading hierarchy, one which
separates the applications and modules from each other, and from the application
server. This hierarchy is strongly based on the hierarchy of the classloaders in stan-
dard Java. Classes from the application server are shared between the applications
through a common parent classloader; this means that application classes can't easily