zondag, augustus 26, 2007

Secrets of Bundle-NativeCode

The OSGi Bundle-NativeCode manifest header is one of those well kept secrets of Eclipse. It allows you to use native libraries (DLLs) without having to set the java.library.path system property. SWT is the most notorious example of this.

Today I was struggling to get a use case with three DLLs working: xp.dll is specific for Windows XP, vista.dll is specific for Windows Vista and both.dll is needed on both platforms. How can you get this to work with a Bundle-NativeCode manifest header?

Adding the following line to your plug-in's manifest does not work:
Bundle-NativeCode: /lib/both.dll; osname=win32; processor=x86, /lib/xp.dll; osname=winxp; processor=x86, /lib/vista.dll; osname=winvista; processor=x86
The reason why this does not work is mentioned in bug 118065 and described in full details in the javadoc of BundleNativeCode.java:
If you have more than one library for the same environment then you should include all of the libraries for that environment in the same Bundle-NativeCode entry.
So, after changing the above line (with three entries of each one library) into the following (with only two entries of each two libraries), everything worked just fine:
Bundle-NativeCode: /lib/both.dll; /lib/xp.dll; osname=winxp; processor=x86, /lib/both.dll; /lib/vista.dll; osname=winvista; processor=x86
While investigating this, I also found two interesting lists to bookmark: the supported processor aliases and OS aliases.

3 opmerkingen:

  1. Another link: the actual OSGi specification.

    I had a quick look (p57 of the core specification) and it looks like equinox' implementation is correct.

    The specification even goes the extra mile and spells out the algorithm an implementation should use in 3.9.1.

    I wish every specification was that clear :)

    The only thing that irks me though, is that you have to give the OSGi Alliance your email address before you're allowed to download the specification.

    Removing this nuisance would be an easy way to make the "Open Service Gateway" even more "Open" ...

  2. There's no developer left behind in PDE :)


  3. As of SWT 3.3, you no longer need to set java.library.path.