Thomas Watson wrote: > Tim Ellison <[EMAIL PROTECTED]> wrote on 01/04/2006 09:08:49 AM: > >>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. > > I assume by exports file you mean the bundle manifest file > (META-INF/MANIFEST.MF). This is where you define your package exports > and a Bundle-NativeCode header as well as other OSGi define manifest > headers and directives which the runtime (or Framework) understands.
No, I really mean the exports file (.def/.exp) for functions 'exposed' from the native library, be they JNI functions or 'regular' C functions. >>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. > > I'm not sure I understand. In OSGi native code is delivered with the > bundle as jar entries within the bundle jar. The Bundle-NativeCode > header is used to specify the paths to native code and certain directives > which must match for the native library to be used. For example, > OS name/version, architecture etc. > > This binds the native code directly to the version of the bundle it > is delivered in. Right, so I think it makes sense to forego the platform's solution (such as an ELF version script [1]) in this case, and reflect any changes to the exported C functions as a change in the bundle version number; i.e. treat the Java code and native code combined as the bundle. >>So I think coupling the native library and java version info in the >>bundle version number makes sense. > > The new selection-filter mechanism provided in OSGi R4 should allow > you to specify a matching filter for a specific java.version value. > For example: > > Bundle-NativeCode: > linux_x86/libNative.so; > osname=Linux; > processor=x86; > selection-filter="(java.version=1.4.*)" > > This indicates that the linux_x86/libNative.so library can only be > used on the Linux OS on an x86 processor and the java property > java.version must match "1.4.*" Understood. >>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... > > Since the native library is delivered with each version of the bundle > there will be two different physical files containing the library. In > most implementations of the Framework the native library is extracted to > disk and the absolute path of the library is returned from the > bundle's ClassLoader#findLibrary method. > >>Any thoughts on loading multiple versions of a bundle containing native >>code? > > With standard OSGi this is already possible because each classloader is > allowed to load different versions of the native library as long as they > are contained in physically different file locations. I see that now thanks to BJ's explanation. > But I'm pretty sure Harmony is not a "standard" OSGi Framework, right? > I imagine you are using OSGi bundle manifest headers to specify > dependencies between the different class libraries, but at runtime you > are actually loading all the code with the same classloader (the boot > classloader). If the same classloader is used for each class library > version then you will definately run into issues trying to load different > versions of the same library name. But wait, you would run into the > same problem loading different version of the same class with the same > classloader. So you must be using different classloaders for each > version of the class library, right? Maybe you can explain the > Harmony runtime and how it relates to the OSGi runtime. We are planning on pulling a few stunts that are out of scope of this thread, so for now it is fair to assume that my question relates to normal application code. Regards, Tim [1] http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
