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 embedded 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 XML 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 support an experimental Conditional-Package header which allows to inline packages conditionally: Works as a private package but will only include the packages when they are imported. When this header is used, and will recursively add packages that match the patterns until there are no more additions (quoted from http://www.aqute.biz/Bnd/Format). 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 libraries, these have to be unpacked, place on the filesystem and added to the class loader.

The 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 to 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 in 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 be 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...