[equinox-dev] Optional relaxing of constraints on native libraries?

[Jennifer Fogell <jfogell@xxxxxxxxxx>]

I have some comments and a proposal regarding OSGi RFP 44 section 4.1.6
"Relax constraints on presence of native libraries".

In looking over the use cases for section 4.1.6, I found that allowing
bundles to successfully install even when their Bundle-NativeCode does not
match is not a good solution in all cases.

Use case from RFP 44 section 4.1.6.1:
"A bundle has a Bundle-NativeCode header which references native libraries
for different platforms. The bundle does not contain the native libraries.
There are bundle fragments for the bundle which each contain the specific
native library for a specific platform. The proper fragment is installed
which provides the native library referenced by the base bundle. The native
library can now be loaded from the bundle fragment. This allows the base
bundle to contain a complete Bundle-NativeCode header naming all known
native library implementation but the base bundle does not have to incur
the penalty of containing all the native libraries. The proper fragment
containing the required native library will be selected and installed by
the management system."

In this case the Bundle-NativeCode can simply be specified in the
fragment's manifest file instead of the host's manifest file.  The host
does not need to specify the native code that a fragment is providing.  If
the host's classloader can not find the native code, it then proceeds to
check it's fragments for native code.

Use case from RFP 44 section 4.1.6.1:
"A bundle provides a crypto API to other bundles. This bundle contains an
all Java implementation of the crypto API so that it operates on all
platforms. The bundle also contains native implementations of the crypto
library for some platform as a performance enhancement. The bundle’s
manifest has a Bundle-NativeCode header which lists the native libraries
for the specific platforms. If this bundle is installed on a platform for
which there is no matching clause specified in the Bundle-NativeCode
header, the
installation will fail even though the bundle is able to function by using
the all Java implementation. This requirement would allow the installation
of the bundle to succeed. "

In this case we should allow the installation, resolving and starting of
the bundle to succeed even though there was no match in the
Bundle-NativeCode.  The problem with allowing every bundle with a
non-matching Bundle-NativeCode tag to install is that we have no way of
knowing if the bundle was designed to work without any native code.

I propose that the successful installation of a bundle with a non-matching
Bundle-NativeCode header be optional.  An optional flag could be specified
in the Bundle-NativeCode header.  If the flag is set, then the bundle
should not fail to install due to a native code mismatch.  A '*' could be
used to specify the flag.  For example:

A Bundle-NativeCode header that looks like this:
Bundle-NativeCode:crypto.dll;osname=linux;processor=x86
would result in the bundle being installed only when the processor and
osname match (as it currently does today).

A Bundle-NativeCode header that looks like this:
Bundle-NativeCode:crypto.dll;osname=linux;processor=x86,*
would result in the bundle being installed even when the processor and
osname do not match.  In this case, no native libraries will be loaded from
the bundle for any System.loadLibrary calls.

I will add these comments to bugzilla PR 41072.

regards,
Jennifer Fogell
 Pervasive Development
 IBM Software Engineer
 Ext 838-9246  T/L 678-9246