Speak like a native – How to use native code (Windows DLL) in OSGi

As you know the OSGi Framework enforces strong modularity. This also applies to native library code, e.g. a Windows DLL.

To make your DLL available in the context of OSGi you have to use the Bundle-NativeCode section in MANIFEST.MF.

For example if your DLL is called “sapjco3.dll” and is in the main path of you bundle you can use.


Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Jco
Bundle-SymbolicName: com.sap.conn.jco
Bundle-Version: 1.0.0
Bundle-ClassPath: sapjco3.jar
Bundle-NativeCode: /sapjco3.dll; osname=win32; processor=x86
Export-Package: com.sap.conn.jco,

Many thanks to Matthias Heinrich for the tip.

Update: You can also maintain several architectures at the same time for example:

Bundle-NativeCode: /sapjco3.dll; osname=win32; osname=win64; processor=x86; processor=x86_64

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, With more than one million visitors per month his website vogella.com is one of the central sources for Eclipse and Android programming information.
This entry was posted in Eclipse, OSGi and tagged . Bookmark the permalink.

5 Responses to Speak like a native – How to use native code (Windows DLL) in OSGi

  1. Alex Blewitt says:

    Note that the DLL is loaded once: so if you do this, you should really make the bundle a singleton as well. If you uninstall and reinstall the bundle it may not be possible to install and reload it in the same process.

    Also, the DLL interdependencies can be a problem. It’s best to have a shim which provides a (constant) Java API, then code tour vundles against that API in a different bundle.

  2. Lars Vogel says:

    @Alex thanks for the clarification.

  3. @Alex

    Do you know why the unload limitation exists? I know you can load/unload .so’s on linux, I assume mac and windows allow it as well.

  4. masaya says:

    Does the Dlls have to be in the *main path* of our bundle ?
    I tried to put it in sub folder. such as /native/sapjco3.dll.
    But It failed…

  5. Lars Vogel says:

    @masaya in this case the jco3.jar expects the .dll on the same level. This is not a limitation of OSGi.

Comments are closed.