OSGi revealed - OSGi in Action - page 5

improve maintainability by enforcing the logical module boundaries; we'll discuss more
modularity details in chapter 2.
The notion of modularity isn't new. The concept became fashionable back in
the 1970s. OSG i technology is cropping up all over the place—for example, as the
runtime for the Eclipse IDE and the GlassFish application server. Why is it gaining
popularity now? To better understand why OSG i is an increasingly important Java
technology, it's worthwhile to understand some of Java's limitations with respect to
creating modular applications. When you understand that, then you can see why
OSG i technology is important and how it can help.

1.1.1 Java's modularity limitations

Java provides some aspects of modularity in the form of object orientation, but it was
never intended to support coarse-grained modular programming. Although it's not
fair to criticize Java for something it wasn't intended to address, the success of Java has
resulted in difficulty for developers who ultimately have to deal with their need for
better modularity support.
Java is promoted as a platform for building all sorts of applications for domains
ranging from mobile phone to enterprise applications. Most of these endeavors
require, or could at least benefit from, broader support for modularity. Let's look at
some of Java's modularity limitations.

LOW-LEVEL CODE VISIBILITY CONTROL
Although Java provides a fair complement of access modifiers to control visibility (such
as public , protected , private , and package private), these tend to address low-level
object-oriented encapsulation and not logical system partitioning. Java has the notion
of a package , which is typically used for partitioning code. For code to be visible from
one Java package to another, the code must be declared public (or protected if using
inheritance). Sometimes, the logical structure of your application calls for specific
code to belong in different packages; but this means any dependencies among the
packages must be exposed as public , which makes them accessible to everyone else,
too. Often, this can expose implementation details, which makes future evolution
more difficult because users may end up with dependencies on your nonpublic API .
To illustrate, let's consider a trivial “Hello, world!” application that provides a pub-
lic interface in one package, a private implementation in another, and a main class in
yet another.

Listing 1.1 Example of the limitations of Java's object-orientated encapsulation

package org.foo.hello; Greeting.java

public interface Greeting {
void sayHello();
}

Simple
interface

B

package org.foo.hello.impl; GreetingImpl.java
import org.foo.hello.Greeting;