Java Reference
In-Depth Information
and maintainable. But the
OSG
i programming model is pretty low-level. It doesn't
have much to say about transactions, persistence, or web pages, all of which are essen-
tial underpinnings for many modern Java programs. What about a combination,
something with the best features of both enterprise Java and
OSG
i? Such a program-
ming model would enable applications that are modular, maintainable, and take
advantage of industry standard enterprise Java libraries. Until recently, this combina-
tion was almost impossible, because enterprise Java and
OSG
i didn't work together.
Now they do, and we hope you'll agree with us that the merger is pretty exciting.
We'll start by taking a look at what modularity is, and why it's so important in soft-
ware engineering.
1.1
Java's missing modularity
When it was first introduced, in 1995, Java technology represented an enormous leap
forward in software engineering. Compared to what had gone before, Java allowed
more encapsulation, more abstraction, more modularity, and more dynamism.
A decade later, some gaps were beginning to show. In particular, the development
community was desperate for more encapsulation, more abstraction, more modular-
ity, and more dynamism. Java's
flat classpath
structure wasn't scaling well for the mas-
sive applications it was now being used for. Developers found that, when deployed,
their applications picked up a bunch of classes from the classpath that they didn't
want, but were missing some classes that they needed. In figure 1.1, you can see an
example of a typical Java classpath.
It was impossible to keep component internals private, which led to constant argu-
ments between developers (angry that the function they relied on had been changed)
and their counterparts, who were annoyed that developers had been coding against
things that were intended to be private. After 10 years of continuous development,
there was an urgent need to be able to label the many iterations of Java code that were
out there with some sort of versioning scheme. Core Java was starting to feel pretty
tightly coupled and undynamic.
Class A
Class B
Class C
Class D
Class E
Class F
Class G
Class N
Class M
Class L
Class K
Class J
Class I
Class H
Class O
Class P
Class Q
Class R
Class S
Class A!
Class T
Figure 1.1
Conventional Java has a flat classpath which is searched in a linear order. For large ap-
plications, this classpath can be long, and searches can be time consuming. If a class occurs more
than once on the classpath, only the first instance is used—even if the second copy is better.
