> From: Mike Wilson <[email protected]> > There are of course many variations on how you can bundle up API > suitable for clients on different versions in the same artifact. F > ex, Microsoft in their COM interfaces just adds new types with an > incremented sequential number, which would correspond to: > interface NewOsgiFeature { > void doStuff(Runnable r); > } > interface NewOsgiFeature2 extends NewOsgiFeature { > <T> void doStuff(Callable<T> c); > } > The only requirement is that API that require the class library of > newer Java versions are kept in separate class files.
That is not enough. The separate class files also need to be in a separate package. You don't want to pollute a class space with classes that cannot be loaded by the JRE. You also don't want the API build environment to have split package situation where some classes are build in one project with one JDK and another project with another JDK. > > But I'm not proposing one model over the other, but trying to ask > the general question whether OSGi may benefit from providing > different API levels depending on the Java version used? (or if it > has ever been discussed, what came out of it, etc) It may but we, in the OSGi expert groups, have not found that compelling case yet. > > Adding two more alternatives (0) and (3) to make a more complete > picture on how one can handle version lag wrt Java: > > 0) Keep things so simple that >Java 1.4 types are never needed > 1) Back-port good stuff from >Java 1.4 for all environments > 2) Provide richer optional API (with native types) for >Java 1.4 environments > 3) Increment lowest Java version more often (for new major releases > of own product) to keep shorter distance to latest Java > > Many Java frameworks use (3) to avoid too much pain with lagging > behind. My impression was that OSGi was adhering to (0) so I was > surprised to see (1) in the Async spec. Right now, OSGi has a Residential Spec which is being deployed in residential gateway devices which have embedded Java ME CDC/Foundation runtimes. So the issue is not just trying to be backwards compatible to be nice but because we have real users right now who need to run OSGi on Java ME CDC/Foundation runtimes. This is caused by Sun/Oracle not providing an update to the Java ME CDC user base for a long time. Soon that may be fixed. > > OSGi is keeping a record long backwards compatibility, which of > course has benefits, but causes pain too. From the four > alternatives, personally I find (1) the least desirable as it > violates separation of concern and duplicates API space for many > users. But YMMV of course. > > So do I understand correctly, that OSGi primarily follows option (0) and (1)? I don't think OSGi has a philosophy as written out as yours. We are driven by our user bases which include Java ME CDC/Foundation users and Java SE/EE users which are using a mix of Java 5/6/7 runtimes. > > Or can we expect the shift to Java SE 8 Compact Profile 1 to be > followed by more frequent updates in the future, achieving (3) ? (or > is it probable that Java 8 will stick as long as Java 1.4 has now?) Assume the replacement of Java ME CDC/Foundation by Java SE Compact Profile 1 in the Oracle product line and that Oracle (and other embeded java vendors) keep their embedded offering up to date with Java SE, then OSGi will be able to move forward on an ongoing basis. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
