Speak like a native – How to use native code (Windows DLL) in OSGi
by Lars Vogel / July 27th, 2010
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.
Tags: OSGi
Filed under: Eclipse
July 27th, 2010 at 1:50 pm
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.
July 27th, 2010 at 2:02 pm
@Alex thanks for the clarification.
July 29th, 2010 at 7:16 am
@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.
July 30th, 2010 at 3:21 am
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…
July 30th, 2010 at 9:28 am
@masaya in this case the jco3.jar expects the .dll on the same level. This is not a limitation of OSGi.