Other OSGi blogs |
Why Did We Let Jini Out of OSGi R4
2005-11-17
The OSGi Service Platform Release 4 was the first release where we actually dropped a specification. In R3, there was a special section that we named “Recommended”, clearly indicating that they were no specifications. It contained the UPnP™, JINI, Namespace, and Initial Provisioning recommendations.
So in R4 we needed to make the decision to elevate these recommendations to specification status. The UPnP and Initial Provisioning recommendations were obvious candidates for elevation while the Name Space recommendation was just as obvious for removal. The Jini recommendation was a harder because Jini itself was not completely dead. So after some soul searching we decided to remove the Jini recommendation for the following reasons:
So where the UPnP recommendation had several members highly interested, no such defenders could be found for the Jini recommendation. Also looking at the outside world, it is clear that the UPnP adoption is gaining momentum, in contrast with Jini.
Personally, I absolutely loved the Jini specifications, never read a more well written architecture specification. However, after I spent some serious time with it, which was in 1997 when I first met Jon Bostrom selling Jini together with Billy Joy, I was very disappointed. The implementation was so bad, that I have a hard time believing they have been able to solve all the problems in these 8 years.
I must admit I am surprised it keeps popping up in different places, but it somehow refuses to die, regardless of the number of places where it fails. Ever seen a consumer Jini device?
Interestingly, Service Location Protocol (SLP) seems to be popping up its pretty head again. This is intriguing because SUN, as author of SLP and JINI, politically decided to assassinate SLP in favor of Jini. SLP (as I recall) supports a mode where it carries a JAR file, which is of course a perfect match for OSGi. And SLP is basically the Jini network discovery protocol without the additional the requirements for Java and its security implications.
Maybe the OSGi should take a look at SLP? Let me know.
Peter Kriens
OSGi Evangelist
So in R4 we needed to make the decision to elevate these recommendations to specification status. The UPnP and Initial Provisioning recommendations were obvious candidates for elevation while the Name Space recommendation was just as obvious for removal. The Jini recommendation was a harder because Jini itself was not completely dead. So after some soul searching we decided to remove the Jini recommendation for the following reasons:
- None of the members showed any interested in this recommendation or defended it.
- Jini was considered more or less on life-support if not already declared dead.
- Security implications that are caused by Jini were not compatible with the strong security model of the OSGi specifications.
- Complex interactions between class loaders made the use of Jini cumbersome.
- The problem of loading ill-defined code in your VM
So where the UPnP recommendation had several members highly interested, no such defenders could be found for the Jini recommendation. Also looking at the outside world, it is clear that the UPnP adoption is gaining momentum, in contrast with Jini.
Personally, I absolutely loved the Jini specifications, never read a more well written architecture specification. However, after I spent some serious time with it, which was in 1997 when I first met Jon Bostrom selling Jini together with Billy Joy, I was very disappointed. The implementation was so bad, that I have a hard time believing they have been able to solve all the problems in these 8 years.
I must admit I am surprised it keeps popping up in different places, but it somehow refuses to die, regardless of the number of places where it fails. Ever seen a consumer Jini device?
Interestingly, Service Location Protocol (SLP) seems to be popping up its pretty head again. This is intriguing because SUN, as author of SLP and JINI, politically decided to assassinate SLP in favor of Jini. SLP (as I recall) supports a mode where it carries a JAR file, which is of course a perfect match for OSGi. And SLP is basically the Jini network discovery protocol without the additional the requirements for Java and its security implications.
Maybe the OSGi should take a look at SLP? Let me know.
Peter Kriens
OSGi Evangelist
Add a comment