OSGi revealed - OSGi in Action - page 18

access the service object instance C . The service reference can be safely stored in a
member variable; but in general it isn't a good idea to hold on to references to service
object instances, because services may be unregistered dynamically, resulting in stale
references that prevent garbage collection of uninstalled bundles.
Both the service implementation and the client should be packaged into separate
bundle JAR files. The metadata for each bundle declares its corresponding activator,
but the service implementation exports the org.foo.hello package, whereas the cli-
ent imports it. Note that the client bundle's metadata only needs to declare an import
for the Greeting interface package—it has no direct dependency on the service
implementation. This makes it easy to swap service implementations dynamically with-
out restarting the client bundle. To see this example in action, go to the chapter01/
greeting-example/service/ directory in the companion code and type ant to build the
example and java -jar main.jar to run it.
Now that you've seen some examples, you can better understand how each layer of
the OSG i framework builds on the previous one. Each layer gives you additional capa-
bilities when building your application, but OSG i technology is flexible enough for
you to adopt it according to your specific needs. If you only want better modularity in
your project, use the module layer. If you want a way to initialize modules and interact
with the module layer, use both the module and lifecycle layers. If you want a dynamic,
interface-based development approach, use all three layers. The choice is yours.

1.3.4 Setting the stage

To h e l p i n t r o d u c e t h e c o n c e p t s o f e a c h l a y e r i n t h e OSG i framework in the next three
chapters, we'll use a simple paint program; its user interface is shown in figure 1.7.

Figure 1.7 Simple paint
program user interface