a component deployment model, also known as JRE modularity, for the core of J2SE 5.0 and Java SE 6 without breaking Java compatibility. The technology’s been in production use for more than two years and proved effective. I’ve recently outlined the necessary deployment tools and Java runtime machinery in this Excelsior blog post
Given that Project Jigsaw
is emerging in JDK 7, I offer some insights on the challenges that any implementation of modularity for the Java SE core may face.
The corporate battle around OSGi needs a break. None has won and the Java Community has lost because, time after time, JRE modularity solutions appear to disappear (remember JSR-277
). To use or not to use OSGi now is less of an issue as compared with the next challenge.
In modular approach, each component should be sufficiently isolated and import relations should be declared statically
. Besides that, import graph should be (close to) acyclic
to minimize the number of indirectly used components.
The problem is that the reference implementation of the Java SE API was coded without having modularity in mind. Somewhat it was a side-effect of the Java’s lazy classloading which created an illusion that a use of any class in Java code costs nothing until it’s actually executed at run time. It’s proved to be a technical debt
and now is the time to pay the interest.
In practice, it means that spaghetti-like dependencies between the implementing classes are omnipresent and breaking the ties without breaking backward compatibility with previous Java versions is double tough. The danger is to create something like Apache Harmony: everything is implemented with an elegant internal architecture, samples work, but existing Java apps have issues.
Need for total modularization.
There is a risk to get no benefits from the JRE modularity alone. Most real world applications use third-party components (Java APIs), which are yet to be modularized. Typically, applications tend to use only a part
of the functionality provided by an API. Without total modularization, chances are good that unnecessary parts of (modularized) JRE will be taken in due to use of a (monolithic) third-party component. And it’s no matter whether the import declarations will be written in OSGi bundle manifests or somewhere else.
What do you think of the above?