| [cross-project-issues-dev] New generified API comming in OSGi for Indigo (M2) |
For the next release of the OSGi specification (R4.3) the core OSGi APIs will be adding generics and adding a few other methods. As a result, there are going to be cases where source code compatibility will be broken. Note that this is not a statement about binary compatibility. The next release of the OSGi specification will be binary compatible. Source code compatibility is only an issue if you are compiling code against the new version of the OSGi APIs. In some cases you will find that code that compiles fine on older versions of the OSGi API will no longer compile against the latest versions.
For Indigo M2, Equinox will release the first set of changes to the OSGi API for the R4.3 specification. In fact I already released the initial set of changes in to HEAD now that M1 is done for the equinox project. Below is a summary of the potential source code compatibility issues you may experience when compiling your code against Equinox M2.
A method on BundleContext may introduce method ambiguity.
BundleContext.getServiceReferences(Class<S>, String)
This new method will introduce ambiguity with the old method BundleContext.getServiceReferences(String, String) if you are using a null value for the first parameter. The fix is to add a cast to (String) for the first argument (e.g. bc.getServiceReferences((String) null, filter))
Some cases where a Dictionary object is used the API has been updated to use generic types Dictionary<String, ?>. This has been changed for the following:
BundleContext.registerService(String[], Object, Dictionary<String, ?>)
BundleContext.registerService(String, Object, Dictionary<String, ?>)
Filter.match(Dictionary<String, ?>)
Filter.matchCase(Dictionary<String, ?>)
ServiceRegistration.setProperties(Dictionary<String, ?>)
If you code is compiled against JavaSE 5 or greater and you have specified generic types for a Dictionary that is not compatible with Dictionary<String, ?> then you will get a compile error if that Dictionary is used in one of the above methods. There are a few options to fix this:
1) change the type of your Dictionary to Dictionary<String, ?>
2) copy your Dictionary into a properly typed Dictionary. (not recommended for performance)
3) cast to the raw Dictionary type before invoking one of the above methods. This is the most simple and will continue to work because the implementations must handle Dictionary objects with non-String key values (which is to ignore them); otherwise binary compatibility would be broken.
The dictionary returned by Bundle.getHeaders methods is now of type Dictionary<String, String>. This may cause similar issues as above if the variable you are assigning the result to is not compatible with Dictionary<String, String>. In this case the most simple thing to do is to change your variable type to Dictionary<String, String>.
You can make these changes to your source code now and it will continue to compile and run on older versions of the OSGi API and you will be ready to compile against the new version of the API as well.
Also note that there is a known issue in JDT that causes strange errors in the Java editor when your project is using J2SE 1.4 compiler settings and you have the latest org.eclipse.osgi project checked out from HEAD (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=305259)
Let me know if you have any questions or concerns. Thanks.
Tom