Option 2 looks hideous and never ends. Soon there is a org.osgi.feature.java6 and a org.osgi.feature.java7 and a org.osgi.feature.java8 package! The API is not cohesive and spread out over an open ended number of packages.
Your example is not a great one in that the additional of Callable only lets the Callable implementation throw checked exceptions. Any return type is uninteresting since Runnable is ok and it has no return type. A better example is an actual issue we have right now with Java 8 and its new java.util.function package. We want to use Function and Predicate in Promise but don't want to require Java 8 to use them. So for now we will define our own equivalents (option 1) which will work on all Java versions. But this wont be a practical issue for Java 8 users anyhow since with lambda expressions, the compiler can easily infer the OSGi equivalent functional interface. In the future, once Java 8 is the base Java level for all OSGi (like when Java ME CDC/Foundation is officially replaced by Java SE 8 Compact Profile 1), we can then add support for the actual java.util.function functional interfaces by method overloading (for those people not using lambda expressions). -- 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 From: Mike Wilson <[email protected]> To: "'OSGi Developer Mail List'" <[email protected]> Date: 2014/03/14 11:32 Subject: Re: [osgi-dev] use of classes >java1.4 in APIs? Sent by: [email protected] Thanks for the reference to the Compendium spec, BJ. And yes, generics is fine - it's references to classes in the Java class library I'm concerned about. I find the question about optional parts of APIs interesting in principle, as not doing it may lead to creation of duplicate functionality. A contrived example to illustrate follows. Let's say this is what we would like to offer for everyone: interface NewOsgiFeature { void doStuff(Runnable r); } but for modern/complete JVMs for convenience we would like to offer: interface NewOsgiFeature { void doStuff(Runnable r); <T> void doStuff(Callable<T> c); // Needs Java 1.5 } Ie, we consider support for Runnable as a sufficient baseline and could let applications on limited environments make their own workaround for Callable-like scenarios. Now there are two ways of introducing Callable support: 1) Back-porting and make our own Callable interface OsgiCallable<T> { <T> call(); } interface NewOsgiFeature { void doStuff(Runnable r); <T> void doStuff(OsgiCallable<T> c); } which offers Callable-like functionality on all environments by cloning classes from later Java versions. 2) Use optional API package org.osgi.feature; interface NewOsgiFeature { void doStuff(Runnable r); } package org.osgi.feature.java5; interface NewOsgiFeature extends org.osgi.feature.NewOsgiFeature { <T> void doStuff(Callable<T> c); } which offers true Callable functionality on supported environments and avoids duplication. The client chooses desired compatibility level by importing NewOsgiFeature either from the org.osgi.feature or org.osgi.feature.java5 package. Have there been previous discussions about solutions like the latter? What's the reasoning around optional APIs vs duplication/backporting? Best regards Mike BJ Hargrave wrote: > From: Mike Wilson <[email protected]> > Are there any good references to the thinking behind what > classes are allowed to use, and not to use, in OSGi APIs? The best "reference" would be the OSGi Minimum Execution Environment. See section 999 on the OSGi Compendium Release 5 specification. By limiting APIs to use types in ee.minimum, we know the APIs will be usable on Java SE 1.4 and later including Java ME CDC-1.1/Foundation-1.1 (which is used by OSGi users in embedded environments.) > > And what about having optional parts of OSGi APIs that may > use classes from a wider range of execution environments? In a specification, we try to minimize optionality since it makes it harder for bundle implementors. Some of the specifications do require later versions of Java if their underlying technology does. But we generally try to limit API usage to types in ee.minimum for the broadest reach. We do use generics in some API because we know we can compile with older javac compiler with -target jsr14 to support Java ME CDC-1.1/Foundation-1.1 VMs. Those classes are compiled with -target 1.5 in the normally distributed companion code jars so they can be used in Java SE 1.7 (and later) build environments since Java SE 1.7 javac ceased to recognize -target jsr14 class files. -- 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
