river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Jini.org
Date Sun, 28 Jun 2009 04:17:13 GMT
On Fri, Jun 26, 2009 at 11:39 PM, Gregg Wonderly<gregg@wonderly.org> wrote:
> As statement of my perspective...
> IBM leads the OSGi thrust, and the bad taste that I got from IBM/Eclipse
> doesn't leave me feeling excited about doing anything to "work with" IBM.  I
> found it to be impossible to "work with" eclipse developers.  They insisted
> it was their way or the highway.

I am pro-OSGi and anti-Eclipse. I have for long been supporting the
people who are outside the Eclipse/Equinox "mentality" and I have very
little respect for the 'cave-ins' that happened quite a few years ago
now, when Eclipse folks black-mailed OSGi into features that OSGi
doesn't need.
We now have one more similar player in the space, i.e. SpringSource,
which will also be dictating quite a few things in the Alliance-space.

That said, one can actually live quite happily with OSGi, without
paying much attention to what Eclipse/IBM are doing. Apache Felix
project is a rich eco-system of OSGi tools and components, including
probably the best framework implementation (seen from a maintenance,
code-size, stability point of view), and I am also the founder of the
"Pax project" at http://wiki.ops4j.org where we create
platform-agnostic tools, according to specs instead of incidental
trial-error methods.

> I am interested in simple software assembly techniques.  I am interested in
> manageable software systems.  Currently, I have no problems getting all of
> this out of using Jini and the power of the Java ".jar" mechanisms and
> dynamic class loading features of the language.

Well, one thing that I always opposed was the opaqueness of the RMI
classloader mechanism. It is very unclear how the RMI classloader
really works, when classes are dropped and reloaded and what not.
IMHO, it is a fluffy model, where one more or less code incidentally.

> OSGi from the outside doesn't seem to be "adding" anything to the features
> that I need.

If you don't want modularization and a promised of module reload in
runtime, then I guess there are many system to choose among.

>  I currently use netbeans, and not eclipse.  I currently don't
> have a software development system nor a server deployment system based on
> OSGi.  So, I don't have an easy road to using, trying or developing in the
> OSGi "way".

Uhhh... You don't need Eclipse. I have not used Eclipse for OSGi
development ever. The OSGi specific plugins, known as the Plugin
Development Environment, is a buggy piece of shit that for years
didn't even comply to the OSGi spec. Many people I know, who uses
Eclipse, don't use the OSGi features, just plain JDT. Personally I am
on IDEA and rely heavily on Pax and Felix tools to get the job done.

> The divisions in systems that developments like OSGi create, are not near as
> helpful as they could be if OSGi developers would snuggle up with others in
> the industry already doing such things.

The problem is that OSGi should have been adopted by Sun for the JVM
back in 1998/1999, to provide a rich and deterministic classloading
model, and everything built on top. Now, that didn't happen and the
OSGi community is trying to slide OSGi in *under* existing
technologies with varying degree. Some applications and subsystems are
just making too much assumptions of the Java environment (the J2EE
classloader hierarchies, only unload if JVM stops, rely on OS cleanup
of resources and what not) and will break when running in OSGi

> From my perspective, the lack of IBM/OSGi knocking on the door, and the lack
> of there being netbeans plugins and other more "ever present" OSGi "stuff"
> visible in day-to-day Java news, really tells me that IBM is once again,
> like Eclipse, on the path of "Our way or the highway", trying to not work
> with anyone else. NIH seems to be the name of the game, and they will either
> steam roll everyone into submission, or they will fail because such a huge
> wall gets built up around them, that they can't get through.

That is a strawman. Eclipse didn't invent OSGi. Eclipse/IBM put very
strong demands on the OSGi Alliance on new features in the Release 4.0
specification, otherwise they wouldn't adopt OSGi. Some of those
features (e.g multiple versions of the same classes) were good,
whereas I think others are just bad (RequiredBundle, Fragments) but
was said to be required to allow reasonable effort for converting
Eclipse to OSGi.
The NIH argument is IMHO more prevalent in Sun, who insisted on
JSR-277 until recently, which overlaps partially with OSGi, especially
the bits that were moved to JSR-294, which we may live with whether
you Gregg like it or not. OSGi is at least an optional choice at the
moment, and I would like it to continue that way.

> The absolute panic that the Java community was in when it looked like IBM
> might buy Sun, I believe, speaks directly toward similar feelings, to mine,
> being present elsewhere.

I am not sure that Oracle is any better for Java than IBM would have
been. Oracle has in-principle decisions to port all Java applications
in-house to OSGi, and more importantly to the Eclipse eco-system.
Oracle is probably the strongest OSGi Alliance member from a "work
performed" point of view, especially since BEA is now part of Oracle.
A large portion of the 4.2 release is Oracle driven.

> I'm not saying that I should have these feelings, but I'm just laying my
> biases out so that it is clear where I'm coming from.

Yeah, I know that, but thanks for venting the lungs again. I mean this
is not the first time we have discussed this topic. But I honestly
think that the train has already left the station. OSGi 4.2 includes
remote services, and is IMHO a fairly poor specification, coming from
a SCA/SDO/SOAP angle and no lessons learnt from Jini and other network
fault tolerant systems. Time will tell how well this will work in

Jini/River seems to have fallen into a specialty niche, and perhaps
that is just as fine. Remove the pretense and start get work done.
Comparison; The Apache Etch project is a platform independent RPC
system, which has very specific goals of small footprint,
multiple-languages and so on, with an extremely small community. Yet,
they are active and pushing the project forward and I would expect
graduate sooner rather than later. Apache is a place where it is
enough for a handful of individuals doing the work with zero users,
but Jini probably has 100s and maybe 1000s of people using it in
critical applications. The user base is comparatively large, but
progress on the development front is a lot slower.

Anyway, Sam, I don't think there is any point any more to try and
forge a collaboration between OSGi and Jini. OSGi folks thinks that
Jini's service property matching is too simple and that the overhead
is too complicated, whereas Jini folks pretty much think like Gregg,
OSGi is complicated and brings little to the table.

Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

View raw message