The real story about OSGi and JSR 277

[Neil Bartlett]

Guys, I agree with you that its a shame we can't all just get along,
but this JSR 277 thing really is a problem, and I think Hani has the
wrong take on it. It's a pity that you have simply endorsed his
opinion without checking whether he actually knows what he's talking
about.

First of all, the analogy with Hibernate and JPA just doesn't fit.
Hibernate is a single product, and there are many reasons for not
wanting to base hugely important pieces of IT infrastructure on a
single product -- even an open source one. It makes a lot of sense to
develop a real, cross-vendor specification for O/R mapping within the
JCP, and to model that specification after the existing market leading
product (that is, Hibernate). Note that by the time JPA was published
as a specification, Hibernate was already an implementation of that
specification.

However, OSGi is not a single product, it is already a cross-vendor
specification, which happens to have three open source implementations
already, and a few commercial implementations. So JSR 277 is trying to
come up with a second standard.

Do we need a second standard? Well, if it turns out to be a competing,
incompatible standard, then absolutely not. Given how widely used OSGi
is now, this could cause a really damaging rift in Java.

What if it turns out to be a compatible and complementary standard?
That's what Sun are saying it will be, but you have to wonder in that
case what problem they are trying to solve. After all, OSGi exists and
works already, it's not like we're waiting for Java 7 to come along
with its various tweaks to the language and the JVM for OSGi to start
working properly. It seems highly odd therefore to build an "enabling"
layer underneath a technology that's already "enabled". In the best
case then, JSR 277 will be something that OSGi can just ignore...
okay, there will be bits of it that might be useful like the
repository, but the core of JSR 277 just won't be that useful. For one
thing, there's no way OSGi is going to sacrifice compatibility with
older Java versions by making itself dependent on new features in Java
7.

Will the best case happen? Will OSGi modules be able to interoperate
cleanly with JSR 277 modules? I've been following the JSR 277 EG
mailing list and it doesn't look all that hopeful. At JavaOne the
whole EG got together and Stanley Ho (the spec lead) promised to the
EG that Sun would deliver a "strawman" design for interoperability.
But they still haven't come up with anything to share with the rest of
the EG, and have refused to even let the other EG members participate
in designing the strawman. My strong suspicion -- and this is shared
with others involved in OSGi -- is that the two module system designs
are just too different, and Sun are currently scratching their heads
because they have no idea how to deliver the interop strawman.

Dick, in describing OSGi you said that it was very powerful but
perhaps a little complex. You're right -- when you get into the
details of dynamic services coming and going, multithreading and so
on, there are a lot of things to think about, and maybe not every Java
programmer out there wants to think about those things. There's
certainly a lot of scope for somebody to come along and offer higher
level stuff on top of OSGi that hides the complexity, and that's
exactly what people like Interface21 are doing with their Spring-OSGi
project, or Eclipse is doing with its tooling support, or BEA are
doing with their (proprietary) microServices Architecture. What
doesn't make sense is to come along and offer a lower level
alternative that doesn't interoperate properly with OSGi.

Lastly, you mention that there's a lot of tension between Sun and IBM
over this. Of course, you're right, and there always has been tension
between those two. But look at the list of organisations backing OSGi,
and you find that there's actually tension between Sun and virtually
every other major player in the Java community. For example, BEA are
building ALL of their new products on OSGi; Oracle are deeply invested
in it. Interface21, I've already mentioned. Red Hat too: JBoss is
converting over to OSGi. Then you've got most of the mobile handset
manufacturers; Siemens, Motorola, Nokia, Ericsson, etc. I mention this
merely because IBM is quite unpopular amongst many Java developers --
Hani certainly despises them -- which makes it all too easy to dismiss
this whole issue as simply an evil plot by IBM to take over Java. I
don't like IBM much myself as it happens, but that's just not the
issue here.

I'm sorry, I've gone on too long. However, this is an important
discussion and I think the Posse needs to look into it a bit more
deeply than simply endorsing Hani Suleiman's opinion. I know that
Peter Kriens, the technical director of the OSGi Alliance, would love
to talk to you. What do you say?

Thanks,
Neil

Non-disclaimer: None of the companies mentioned is a client or
employer, nor do I have any financial interest in any of them.

[obitu...@gmail.com]

I don't have much to add to the conversation, but I wanted to throw my
support behind a discussion of this topic on the Posse. Admittedly, I
don't know all the ins and outs of the topic, but I don't understand
Sun's motivation in re-creating something that already exists and is
proven to work within the scope of the current Java language. In my
book, multiple ways to do the same thing is good, a standardized way
to something is better, and a standard implemented by multiple,
independent (and hopefully open source) groups is the best case
scenario. OSGi has achieved the best case scenario, so why start
over? Is there some technical flaw in the OSGi that Sun is trying to
address or are they motivated solely by politics?

Cheers,
Josh

[Jess Holle]

Perhaps Sun is listening to developers who have said they're tired of large, complex, over-engineered standards and want something simple and to-the-point that works.

Taken one way OSGi could be considered the same sort of bloat and complexity that folk like to heap criticism on Sun for about the JDK (which has after all had to provide an extraordinarily high level of compatibility for >10 years).

I'm not saying OSGi is all these things or at least in an unjustified sense, but I can definitely see two sides here.

[Casper Bang]

It kinda reminds me of something we've seen before: EJB3 being just a
copy of Spring + Hibernate. I think Sun likes to be the one pulling
the strings, mitigating the open source aspect somewhat.
Then again, pragmatists such Stephen Colebourne (Joda-time) is the guy
behind finally giving us a decent official date API and Carsten Lentzh
(JGoodies) is part of the swing application (non-)framework. So lets
hope that this buttom-up approach is a growing tendency.

/Casper

[Neil Bartlett]

Jess, I'm curious whether you think OSGi is a "large, complex, over-
engineered standard", or whether you're just speculating about Sun's
motives? Because I assure you, OSGi is already the "something simple

and to-the-point that works".

Casper, again I don't think that EJB3 and Spring+Hibernate is the
right analogy. Spring and Hibernate are products -- where can I
download the BEA implementation of Spring, or the IBM implementation,
or the GPL one? Spring is a great product but it doesn't have a
specification that somebody else can go and implement. Rod Johnson
argues that EJB3 is inferior to Spring, and he might be right, but
nevertheless many people prefer to work from a standard with a spec
than a product which can change arbitrarily in the future. However,
OSGi is already a standard with a specification and multiple
alternative implementations. It's both the "de facto" standard
(because so many people use it) and the "de jure" standard (because
it's been fully ratified under the JCP).

The situation with Joda-time is indeed similar. You can see the
original Date/Calendar APIs in Java as failed specifications, just as
EJB1 and EJB2 were failures. These broken specs drove developers to
adopt a product-based solution which was not broken. Eventually Sun
notices and builds new specs based on (in Spring's case, loosely based
on) the product solution. I agree that this kind of pragmatism is an
encouraging sign.

Regards
Neil

On Aug 23, 3:47 pm, Jess Holle <je...@ptc.com> wrote:
> Perhaps Sun is listening to developers who have said they're tired of
> large, complex, over-engineered standards and want something simple and
> to-the-point that works.
>
> Taken one way OSGi could be considered the same sort of bloat and
> complexity that folk like to heap criticism on Sun for about the JDK
> (which has after all had to provide an extraordinarily high level of
> compatibility for >10 years).
>
> I'm not saying OSGi is all these things or at least in an unjustified
> sense, but I can definitely see two sides here.
>

[Jess Holle]

Neil Bartlett wrote:
> Jess, I'm curious whether you think OSGi is a "large, complex, over-
> engineered standard", or whether you're just speculating about Sun's
> motives? Because I assure you, OSGi is already the "something simple
> and to-the-point that works".
>

I'm speaking to perception, not personal experience here and am purely
speculating on Sun's motives.

--
Jess Holle

[gullcatcher]

One of the things that people always point to in the JSR-277 spec is
the maven like repository support.

My suspicion was that this was something that could be built atop of
OSGi.

It's an interesting and small enough problem, that I would do it
myself; but surely it's too useful, for someone not to have done it
already.

Lo and behold, a few searches later, I came across this:

http://felix.apache.org/site/apache-felix-osgi-bundle-repository-obr.html

The OSGi bundle repository! The above link appears to give apt-get or
yum type tools to resolve dependencies from remote repositories.

Coming from Equinox and Oscar environments (those are two
implementations of the OSGi spec) I haven't had any experience with
Felix (that's Apache's implementation of the OSGi framework), so have
only just come across this. Has anyone else? is it ready for prime
time?

If it is, does this have anything to contribute to the 277v291 debate?

G

> > >> but thisJSR277thing really is a problem, and I think Hani has the

> > >> wrong take on it. It's a pity that you have simply endorsed his
> > >> opinion without checking whether he actually knows what he's talking
> > >> about.
>
> > >> First of all, the analogy with Hibernate and JPA just doesn't fit.
> > >> Hibernate is a single product, and there are many reasons for not
> > >> wanting to base hugely important pieces of IT infrastructure on a
> > >> single product -- even an open source one. It makes a lot of sense to
> > >> develop a real, cross-vendor specification for O/R mapping within the
> > >> JCP, and to model that specification after the existing market leading
> > >> product (that is, Hibernate). Note that by the time JPA was published
> > >> as a specification, Hibernate was already an implementation of that
> > >> specification.
>
> > >> However, OSGi is not a single product, it is already a cross-vendor
> > >> specification, which happens to have three open source implementations

> > >> already, and a few commercial implementations. SoJSR277is trying to

> > >> come up with a second standard.
>
> > >> Do we need a second standard? Well, if it turns out to be a competing,
> > >> incompatible standard, then absolutely not. Given how widely used OSGi
> > >> is now, this could cause a really damaging rift in Java.
>
> > >> What if it turns out to be a compatible and complementary standard?
> > >> That's what Sun are saying it will be, but you have to wonder in that
> > >> case what problem they are trying to solve. After all, OSGi exists and
> > >> works already, it's not like we're waiting for Java 7 to come along
> > >> with its various tweaks to the language and the JVM for OSGi to start
> > >> working properly. It seems highly odd therefore to build an "enabling"
> > >> layer underneath a technology that's already "enabled". In the best

> > >> case then,JSR277will be something that OSGi can just ignore...

> > >> okay, there will be bits of it that might be useful like the

> > >> repository, but the core ofJSR277just won't be that useful. For one

[robilad]

Having a debate about specifications behind click-through licenses
(both OSGi and JSR 277 early draft) is pointless, as hardly anyone has
read both of them.

The fundamental purpose of limiting access to specifications through
click-through licenses as practised by OSGi and the JCP is to avoid
the sort of peer review, and informed debate about the specifications
in progress that you'd all desire to have, but can't, because hardly
anyone competent enough (like people distributing millions of JARs to
users through Linux distributions) can be bothered with the spec
licensing legalese in both cases.

On Sep 29, 5:13 pm, gullcatcher <gullcatc...@gmail.com> wrote:
> One of the things that people always point to in the JSR-277 spec is
> the maven like repository support.
>
> My suspicion was that this was something that could be built atop of
> OSGi.
>
> It's an interesting and small enough problem, that I would do it
> myself; but surely it's too useful, for someone not to have done it
> already.
>
> Lo and behold, a few searches later, I came across this:
>

> http://felix.apache.org/site/apache-felix-osgi-bundle-repository-obr....