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 <http://www.osgi.org/> OSGi Alliance
<mailto:[email protected]> [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
