Starting in version 4.3, OSGi started to use generics in some of the API including the Core specification. Generics were introduced to the Java language in Java 5. However, OSGi needed to continue to support embedded use cases which use the CDC/Foundation 1.1 runtime which is still based upon the Java 1.4 language level and JVM. To address this issue, OSGi compiled the APIs with -target jsr14; an undocumented javac flag introduced before Java 5 was final. So we had the best of both worlds: we can use generics and still compile to run on Java 1.4 based runtimes.
This worked for Java 5 and Java 6. But when Java 7 shipped, two things changed: javac no longer understood the jsr14 option to -target and javac refused to recognize the attributes containing the generics information in class files already compiled with -target jsr14. The change to no longer support creating -target jsr14 class files was ok; we could continue to compile with Java 6 javac. But the change to the javac to cease to recognize the class file attributes with the generics information in existing class files was a bigger problem. It meant that the 4.3 API jars published by OSGi were not useable by people who need to compile with Java 7 javac. By not useable, I mean javac treated the classes as if they did not contain any generics information: they were raw. A bug was filed against Java to see if this was some mistake or oversight. The reply was that the change was intentional.
At the time this was first noticed, Java 7 was new and not too widely used. OSGi also included the source code in the jars so you could recompile the code yourself if you needed. Later, when it came time to ship Core R5, we changed to compile the API classes with -target 1.5 and so they work fine on Java 7. So problem solved; the new release's jars don't use -target jsr14! Except some of the current OSGi implementations (I'm looking at you Felix and Karaf) are still based upon Core 4.3 and thus people using those implementations still need to use the Core 4.3 API. And if they also want to use Java 7, they need to recompile the OSGi API source. So after some prodding by a few folks, OSGi rebuilt the Core and Compendium API jars as Core 4.3.1 and Compendium 4.3.1. The new jars have the same packages at the same package versions having the same API signatures. They are just not compiled with -target jsr14 so they work fine with Java 7.
So if you need to use the 4.3 API with Java 7, pick up these new 4.3.1 jars. They should also be available on maven shortly.
So with the OSGi Community Event finishing yesterday the focus now shifts to OSGi DevCon 2013.
We are pleased to be co-locating OSGi DevCon 2013 with EclipseCon in Boston, MA from March 25 to 28, 2013.
The Call For Papers is open and runs until November 19 this year.
However an Early Bird Selection of one talk for the program will be made from the submissions received by October 31.
Yes thats right, the Early Bird Selection deadline is next Wednesday. So you have only 6 days left if you want to maximize your chances of selection and get a free pass to the OSGi DevCon and EclipseCon conference.
We want to hear about experiences from speakers who have deployed OSGi based systems, large and small, as well as embedded, enterprise, or desktop systems. We are also especially keen on tools and frameworks that make it easy to build, use, and deploy OSGi-based applications along with the growing number of uses of OSGi with cloud.
To find out more about how to make a talk submission please visit the OSGi DevCon 2013 conference page.
If you have any questions please contact the OSGi DevCon 2013 Program Committee by email.
We look forward to reviewing your submissions.
OSGi DevCon 2013 Program Committee