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.
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)
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.
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)?
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?)
Best regards
Mike
BJ Hargrave wrote:
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 <http://www.osgi.org/> OSGi Alliance
<mailto:[email protected]> [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 <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>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
