felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Hargrave <hargr...@us.ibm.com>
Subject Re: OSGi, versioning and native code
Date Wed, 04 Jan 2006 15:53:51 GMT
Native code loading is associated with both (a) the class loader and (b) 
the absolute file name. The class loader gets to map the requested lib 
name onto an absolute file name via a call made to 
ClassLoader.findLibrary. The OSGi framework must process the 
Bundle-NativeCode header to make the selected libraries available at some 
bundle unique location so that if each bundle contains libfoo.so, the 
absolute path for each bundle's libfoo.so is unique.

Furthermore, the VM only allows a native library at a given absolute path 
to be loaded only once. This is why the OSGi framework must make sure that 
bundles have unique locations for their native libs. It also means that 
the each revision of a bundle (for this discussion, when a bundle is 
updated you have a new revision) needs to place its native libs in a 
unique location. However, we are still left with some issues around 
refreshPackages which results in a new class loader for the bundle but 
does not change the absolute paths of the bundle native libs.

For more details read section 3.9 (and 3.9.1 in particular) of the R4 Core 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
Office: +1 407 849 9117 Mobile: +1 386 848 3788

Tim Ellison <t.p.ellison@gmail.com> 
2006-01-04 10:08 AM
Please respond to


OSGi, versioning and native code

In Harmony we are splitting up the implementation of the Java class
library itself into components, and using OSGi for guiding principles.

In the java code world, we have got the manifest that defines the
versioned package imports and exports from a module permitting multiple
bundle versions to be active at once.  This is good.

The bit I don't understand is how this model extends to *native* code at
runtime.  The native runtime interface is defined by the exports file.
However, if we rely on native library versioning independently of bundle
versioning we could get into a situation where the runtime can't solve
the bundle dependencies and the library dependencies at the same time.
So I think coupling the native library and java version info in the
bundle version number makes sense.

So then the question I have is how to deal with natives for multiple
versions of a given bundle at runtime?  They need to be in different
named files on windows to reloading a single DLL, so how is that related
to the bundle version number?  Does the bundle activator augment the
load library with a versioned library name? or...

Any thoughts on loading multiple versions of a bundle containing native



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message