To embed or to inline ?

At times you want (or need) to include third party libraries in your bundles. You basically have two options to do that:
  • Embed the complete library
  • Inline the required classes/packages (or everything)
Until recently I was in the camp of embedding the complete libraries and setting the Bundle-ClassPath manifest header accordingly. The Embed-Dependency directive of the Apache Felix Maven Bundle Plugin makes this extremely easy to do.

Lately, though, this has been questioned by Karl Paul's pojosr project. This project brings the OSGi Service Registry to regular applications. The nice thing here is, that it really is a stripped down OSGi Framework basically removing the modularity pillar. The drawback is that this causes the Bundle-ClassPath manifest header and embeddeded libraries to not be supported.

Thus to run your regular bundle inside pojosr, you will have to inline all third party libraries instead of embedding them. The upside is that this really works. For example the Apache Felix Declarative Services implementation works flawlessly after inlining the KXml library.

So, this sparked a discussion of whether embedding or inlining third party libraries is preferrable. And contrary to my former believe (embedding is preferable) it turns out that inlining is probably preferable for a number of reasons:
  • You can just include those classes, that you really need. In fact recent builds of Peter Kriens' fantastic BND tool now supports an experimental Conditional-Package header which allows to inline packages conditionally: Works as private package but will only include the packages when they are imported. When this header is used, bnd will recursively add packages that match the patterns until there are no more additions (quoted from This leads to smaller bundles.
  • The OSGi framework can more easily create the class loader for the bundle, because everything is just contained directly within the JAR file. For embedded libaries, these have to be unpacked, place on the filesystem and added to the class loader.
  • Performance will probably increase because everything is in a single JAR file and does not have to be searched in multiple JAR files
  • Memory Footprint will also be likely be reduced due to only a single JAR file being accessed.
  • Chances are that even the number of consumed filehandles will be reduced.
There is a drawback, though: If you happen to include a signed third party library or a library which you are contractually or by license not allowed to modify, you must embed it completely.

Overall, this discussion changed my mind bringing me to the inline-preference camp...

So, you might expect to see a few of the Apache Felix and Apache Sling bundles I am working on to me modified to inline third party libraries instead of embedding them. In fact the Apache Felix Declarative Services and Web Console projects have already been modified to inline the third party libraries...


Beliebte Posts aus diesem Blog

Ready to serve requests ...

LinkedHashMap's hidden (?) features

OSGi Framework Extension as a Maven Project