Dear James,
I read your interesting interview with eWeek. There were many parts where we agreed, but I was also slightly puzzled with your observations about OSGi. "OSGi is this thing that kind of came from a different universe that's being used for modularity." I do agree that many people see the quality of the OSGi specs as out this world, but that seems a bit exagerated. I do agree we did not start out in the enterprise application space, we started in embedded world where space and performance constraints are pervasive, but after all I thought we both lived in the Java universe. However, this seems at odds with your remarks like "So we needed something that was a lot lighter weight." and "... OSGi's just too much fat."
Hmm, the OSGi core API is 27 classes. That is a all. Security, Module layer, Life cycle layer, and Service Layer. Exceptions, permissions, and interfaces. And one of them is even deprecated! Just the module layer in Jigsaw seems to have more classes, and they just got started ... Or did you mean the implementations? With Concierge at around 80k for an R3 implementation and Felix at 350k it seems a stretch to call us fat? OSGi is even deployed in smart cards.
It's true, our documentation is a bit fat. The core is described in 300 pages. Though we have lots of pictures! And we have virtually no errata, despite the fact that OSGi has been used in tens of thousands of applications over the last decade.
I'd like to tell you a little anecdote. In 1997 I tried to convince Ralph Johnson about Java. My key argument was that Java was so nicely small and therefore easy to understand. Only 11 packages! Ralph, a famous Smalltalker, looked at me wearily and said: "Just wait." Oh boy, was he right. That lesson still drives me every day to keep OSGi lean and mean, annoying many people along the way, but I guess that is the price one needs to pay.
If you think project Jigsaw will be leaner than OSGi, well, modularity is a problem where size does matter. You cannot demonstrate modularity with a Hello World because modularity solves the problem of large evolving code bases. [deleted]
So, James, I think that are lots of details where we did not get it perfect, but OSGi's weight is not one of them. The misconceptions about OSGi at Sun stand to cost our industry a lot of money and pain in the coming years. Project Jigsaw's simplicity is a fallacy, hidden by the fact that they do not address the hard issues that OSGi has now been working on for over a decade. All major application servers are today based on OSGi, not because it was fun or a hype, but because they had no choice. These are applications in themselves that have a scale where modularity is not an option but a necessity. The success of open source will move many Enterprise applications in this same realm.
If you believe that a simplistic solution can address the needed scale, well than indeed we do live in another universe. However, please remember that we're here as friends, to help, and mean no harm.
Your's sincerely,
Peter Kriens
The "different universe" feeling mostly due to the fact that OSGi was designed for Java 1.3 -- most modern day java developer have never used 1.4.
ReplyDeleteWith the new language feature in later versions, it could be much clear. The question is: would OSGi break backward compatibility for cleaner code?
I agree Peter.
ReplyDeleteI wrote a rebuttal on my blog to that article yesterday...
It's fine to debate technologies, not fine to have clear misconceptions.
@sdiz: There are still an amazing number of people out there that are NOT programming in Java 5. No mobile yet runs Java 5, and there are 9 billions of those out there according to James Gosling.
ReplyDeleteIt is always very dangerous to take your own experiences and declare it as truth, there is a very diverse eco-system out there. Backward compatibility is important, as it is important to include newer features.
That said, the OSGi API is very small and works very well on Java 5, 6, and in the future Java 7. There are very few places where the new futures of Java 5 make sense. However, most application programmers are shielded from these APIs anyway because they use a programming model like Spring, DS, iPOJO, that hides the OSGi API.
A module system is plumbing. You know the shit hits the fan when it stops working but in day to day you should not bother with it.
@Chris: nice blog!
Peter Kriens
Good Job Peter, I am really concerned about James comments, it is clear he is speding too much time at Jenny Craig and not looking at the rest of the world. As the original architect for Mobile Java and the Spec lead for JSR 232 I can safely say that OSGi is not fat. we have released it now on a whole set of Sprint Phones and a "OSGi Java Server in Your Pocket" tells me its not fat
ReplyDeletePeter, very well put. Gosling's comments were either borne of extreme ignorance (which I find very hard to believe) or were politically motivated (more likely).
ReplyDeleteIf they were indeed political motivated, then it would appear that Sun really are digging their heels in on OSGi. Not that we should be overly worried. We live in meritocracy after all.
Peter
ReplyDeleteActually, GlassFish team switched to OSGi because we liked the technology. We wanted to build on it as well as be part of the communities. It really had nothing to do with learning any hard lessons, in fact hk2 is used everywhere in GlassFish today as our programming model and as an isolation layer to the OSGi APIs. And I don't think we particularly hurt any community in the process.
Jerome Dochez
Perhaps what James really means is the size/scope of OSGI. In fact, this is the very thing that Mark Reinhold talks about in the following podcast. Mark also says that they didn't use OSGI because there was/is an immediate need to deliver a module system for java 7 and getting OSGI to make changes would take a long time. He notes that OSGI is much larger in scope than Jigsaw.
ReplyDeletehttp://www.javaposse.com/index.php?post_id=492239
http://www.javaposse.com/index.php?post_id=492239
"So we needed something that was a lot lighter weight."
ReplyDeleteLet's stop on the last two word an remember a comment about him spending too much time with some diet program.
Maybe, this was caused by an obsession or did I watch too much Woody Allen movies ?
In a few words, he showed disrespect to many people with his mistake.
I remember a post or article titled smthg like "using jigsaw might get you fired".
Anyway, too bad He did not 'turn his tongue seven times' before to speak.
Before that, I supposED He knew the 'embedded world' as java was started for being used in embedded software.
Everybody can be wrong sometimes.
Wadaël
@Jerome: I do not think the sentence said GF hurt the community, in my mind the contrary is true. The hurting is referring to the Sun 5 year old drama of modularity. I think the GF team set a great (and courageous) example when they rallied behind OSGi.
ReplyDeleteHowever, the sentence wasn't overly clean and I guess written in frustration. I've deleted it.
@Peter Kriens
ReplyDeleteHi,
I meant that his "So we needed something that was a lot lighter weight." hurt the OSGi community particularly developpers.
I am very glad GF uses OSGi now.
A five seconds startup on a decently recent machine is .... incredible when you are used to JBoss 4.
Well, of course, it is not fully ready (web layer has to be started, apps too).
From my short experience with it, GF merits its success.
I am waiting for V3 FINAL.
I discovered OSGi recently because I work with app servers and it's used in the new versions of GF, JBoss (and maybe others) so I can not discuss the pros and cons of OSGi & jigsaw.
My opinion is that something 10yo and so wide spread should be respected. Even more by someone so influencial.
The article I wrote about in my previous post can be found there :
http://neilbartlett.name/blog/2009/03/25/using-suns-jigsaw-may-get-you-fired/
Peace (and modular coding) for all
Jerome / Wadael
I totally agree with your sentiment and sense, Peter.
ReplyDeleteThe "lightweight" issue reported by Gosling is a non-issue for OSGI.
It must have been spelled out by mistake.
Yet, there must be something "technical" that prevents jdk-7 architects from basing its modularity on OSGI!
(see jsr294)
Whether this is:
* java 1.3 compatibility
* slow evolution
* not controlled by sun-oracle
* ...something else...
it is your burden (the OSGI Architects) to find what that obstacle is
and save us (developers) from having to deal with 2 module-systems.
(Jigsaw & OSGI)