Mastering modularity - OSGi in Action - page 33

(continued)
Annotations are the choice du jour today. Unfortunately, when OSGi work started back
in 1999, annotations weren't an option because they didn't exist yet. Besides, there
are some good reasons to keep the metadata in a separate file, which brings us to
the second school of thought.

This school of thought argues that it's better to not bake metadata into the source
code, because it becomes harder to change. Having metadata in a separate file of-
fers you greater flexibility. Consider the following benefits of having separate module
metadata:
■ You don't need to recompile your bundle to make changes to its metadata.
■ You don't need access to the source code to add or modify metadata, which is
sometimes necessary when dealing with legacy or third-party libraries.
■ You don't need to load classes into the JVM to access the associated metadata.
■ Your code doesn't get a compile-time dependency on OSGi API.
■ You can use the same code in multiple modules, which is convenient or even
necessary in some situations when packaging your modules.
■ You can easily use your code on older or smaller JVMs that don't support
annotations.
Regardless of whether your preferred approach is annotations, you can see that you
gain a good deal of flexibility by maintaining the module metadata in the manifest file.

2.4.2 The bundle's role in logical modularity

Similar to how the bundle JAR file physically encapsulates the member classes, the bun-
dle's role in logical modularity is to logically encapsulate member classes. What precisely
does this mean? It specifically relates to code visibility. Imagine that you have a utility
class in a util package that isn't part of your project's public API . To use this utility class
from different packages in your project, it must be public . Unfortunately, this means
anyone can use the utility class, even though
it's not part of your public API .
The logical boundary created by a bun-
dle changes this, giving classes inside the
bundle different visibility rules to external
code, as shown in figure 2.8. This means
public classes inside your bundle JAR file
aren't necessarily externally visible. You may
be thinking, “What?” This isn't a misstate-
ment: it's a major differentiator between
bundles and standard JAR files. Only code
explicitly exposed via bundle metadata is vis-
ible externally. This logical boundary effec-
tively extends standard Java access modifiers

Exposed packages

Bundle A Bundle B

Private packages

Figure 2.8 Packages (and therefore the class-
es in them) contained in a bundle are private to
that bundle unless explicitly exposed, allowing
them to be shared with other bundles.