When it comes to using existing code with OSG i, packaging isn't the only problem;
there are a number of other issues.
The most common problem people encounter when trying to use enterprise OSG i
for the first time is that they want to make use of their favorite libraries, but don't have
a copy packaged as an OSG i bundle. On hitting this first hurdle, some give up, but
there are a number of simple approaches that you can use to overcome this problem.
Turning normal JARs into OSGi bundles
As we've already mentioned, the Java ecosystem is large and contains a huge number
of libraries providing all manner of functions. Some of these libraries are widely used;
others are specific to certain fields and may only be useful to a handful of developers;
but in all cases, they provide something that other people want to use, and don't want
to have to write for themselves. Because these libraries are developed by such a big
community, you can't rely on them always being provided as OSG i bundles. After all,
not everyone has been using OSG i for the last decade!
Not all libraries are written in Java and packaged as JARs. Sometimes the right way
to perform a particular operation, for example, encryption or vector calculus, is to
communicate with some specialist hardware or to use some optimized assembly
code. These situations are rare for most Java developers, particularly in the enter-
Thanks to its origins in embedded systems, OSGi has a well-designed integration
point for calling native code libraries, but we consider this to be well beyond the
scope of enterprise OSGi. If you're interested in getting native code or other low-level
concepts running in OSGi, then we can recommend OSGi in Action (Hall et al., Man-
ning Publications, 2011) as a useful book on the subject.
When your favorite library isn't packaged as an OSG i bundle, it can't be used in an OSG i
framework, but some effort is usually enough to turn up an OSG i-packaged version.
Finding bundled libraries
It's always a good idea to reuse code in the form of libraries where you can; it saves
effort and tends to reduce the number of bugs in your code. For exactly the same rea-
son, it's a good idea to try to find a copy of your library that has already been turned
into an OSG i bundle. If you do find a bundled copy of your library, then you should
definitely use it. It saves time, and is typically much more reliable at producing well-
formed bundles than other approaches.
You may think that being told to find a bundled copy of your library is a little silly;
after all, the whole point of section 12.1 is that your library isn't an OSG i bundle. On
the other hand, it's unlikely that you're the first person to want to use a given library
in OSG i, and it's definitely worth taking advantage of any existing solutions if you can.
Search WWH ::