Mastering modularity - OSGi in Action - page 39

2.5.3 Code visibility

Human-readable and bundle-identification metadata are valuable, but they don't go
far in allowing you to describe your bundle's modularity characteristics. The OSG i
specification defines metadata for comprehensively describing which code is visible
internally in a bundle and which internal code is visible externally. OSG i metadata for
code visibility captures the following information:

Internal bundle class path —The code forming the bundle

■

Exported internal code —Explicitly exposed code from the bundle class path for
sharing with other bundles

■

Imported external code —External code on which the bundle class path code
depends

■

Each of these areas captures separate but related information about which Java classes
are reachable in your bundle and by your bundle. We'll cover each in detail; but
before we do that, let's step back and dissect how you use JAR files and the Java class
path in traditional Java programming. This will give you a basis for comparison to
OSG i's approach to code visibility.

IMPORTANT! Standard JAR files typically fail as bundles since they were written
under the assumption of global type visibility (i.e., if it's on the class path, you
can use it). If you're going to create effective bundles, you have to free yourself
from this old assumption and fully understand and accept that type visibility
for bundles is based purely on the primitives we describe in this section. To
make this point very clear, we'll go into intricate details about type visibility
rules for standard JAR files versus bundle JAR files. Although this may appear
to be a lesson in the arcane, it's critical to understand these differences.

CODE VISIBILITY IN STANDARD JAR FILES AND THE CLASS PATH
Generally speaking, you compile Java source files into classes and then use the jar
tool to create a JAR file from the generated classes. If the JAR file has a Main-Class
attribute in the manifest file, you can run the application like this:

java -jar app.jar
If not, you add it to the class path and start the application something like this:

java -cp app.jar org.foo.Main
Figure 2.9 shows the stages the JVM goes through. First it searches for the class speci-
fied in the Main-Class attribute or the one specified on the command line. If it finds
the class, it searches it for a static public void main(String[]) method. If such a
method is found, it invokes it to start the application. As the application executes, any
additional classes needed by the application are found by searching the class path,
which is composed of the application classes in the JAR file and the standard JRE
classes (and anything you may have added to the class path). Classes are loaded as
they're needed.