In my role as OSGi Enterprise Expert Group co-chair, I get a lot of questions about OSGi. I thought I'd post some of the more interesting ones here.
First, I was very surprised to hear someone from a large end-user organization say that they would be very interested in using OSGi, if only it were a standard.
The OSGi Specification is as much a standard as any specification developed in the Java Community Process, and more than some. I interpret this as what this person's Java EE vendor has been telling them, privately and in confidence of course, about OSGi.
The OSGi Specification started as JSR 8 back in 1999, and the current version (R4.2) is, as previous versions have been, an evolution of the original work, which was formally handed off from the JCP to the OSGi Alliance at the time. Certainly you could say the scope of modularizing Java (which is the essence of the OSGi Specification, after all) is potentially very broad, and you might question whether its entire potential scope has been standardized.
But you can also look at JSR 291 and see that the previous version of the OSGi Specification (R4.1) has already been officially adopted as a Java specification for a dynamic modularity system. The OSGi Alliance is, if anything, more open than the Java Community Process (and yes, I have participated in each, both at the technical level and the board level - in the case of JCP the former IONA rep elected to the EC reported to me).
Sun has never given up its control over the JCP or any specification it chooses to take the lead on. Anyone can join the OSGi Alliance and participate equally in the development of its specification. This is part of what is meaningful about a standard, that its future direction is open for anyone to participate. No vendor wants to invest a lot in implementing a standard that one of your competitors effectively controls the future of. (Thus the current controversy around the JCP and the whole debate about the future of the Java industry, whether it will continue to fragement etc.)
I suspect what this person really meant was "OSGi is not part of Java EE." That is true. But that is not necessarily a bad thing. I mean, having Java EE based on the OSGi Framework would be great. But having the future of OSGi under the control of the JCP, even to the extent of meeting the requirements of becoming part of Java EE, might not be very helpful to it (or to the future of modular programming in Java).
Before I get on to the next obvious question about Project Jigsaw (which you will notice studiously avoids mentioning OSGi), I want to point out that all Java EE vendors have already adopted OSGi, and built their app servers internally on it (well except JBoss, who has sort of tried to bolt OSGi onto their own microkernel, which seems weird). But they are, so far at least, advising against their customers obtaining the same benefits that motivated them to adopt the OSGi programming model internally - apparently including the argument that "OSGi is not a standard." This does not make sense, at least not for the consumers.
AFIAK Project Jigsaw is Sun's latest attempt to re-invent OSGi, or in any case block OSGi or create a substitute they can control. I understand the potential benefits of modularizing the language itself, and I know that the JSR 294 spec lead (Alex Buckley) spent some time liasing with the OSGi EEG (even attending a meeting and taking the abuse, pretty well anyway - I give him credit for trying to do the right thing), and that JSR 294 (which also studiously avoids mentioning OSGi) in theory is not strictly a documentation exercise for whatever they come up with in the OpenJDK project (which by the way is open in the same sense that the JCP is open - meaning it is under Sun's control), and that also in theory the modularity layer is "pluggable." All of this is sort of meant to indicate that OSGi compatibility or mapping is something the Project Jigsaw folks have in mind, if they are not actually working on it (which they are not as far as I can tell, and they also say nothing about this publicly - apparently only when someone brings up the topic of OSGi).
I was not at Java One this year, so I may have the wrong impression sitting remotely as I am, but my understanding is that the Project Jigsaw talks and demos did not mention OSGi. Nor did the descriptions of the plans for Java 7. So the short answer to the question of whether Project Jigsaw is a threat to Java modularity is that yes, it is.
One more thing to add - I have been following the Project Jigsaw public email list, and from what I could gather what was presented at Java One was more or less equivalent to what they could manage to get done by then. And while the demo looked interesting, and certainly seems to prove they got something working, it also is pretty scary when you think how far away that is from what's already available in the OSGi Framework.
8 years ago
Posts
Hey Eric,
ReplyDeleteI was at the Jigsaw demos. One was part of the keynote Tuesday afternoon and the other was a separate session held on Wednesday. They were the same. Each simply showed how modularizing the JDK could improve download time. The demo was done on Ubuntu. Not much more than that.
One statement that was made, though that was not elaborated upon, was that Jigsaw meets "requirements that aren't met by existing module systems." I captured that quote pretty explicitly. What sticks in my craw, however, is that there was no explanation of what these requirements were. I wish I knew where to find them.
In neither situation was OSGi mentioned. In general, I don't know why Jigsaw exists beyond Sun's desire to control the situation.
Hi Kirk,
ReplyDeleteWhat I've heard before in terms of those additional requirements are language level things that don't necessarily justify re-inventing a perfectly good existing modularity sytsem, but which could provide some benefits if it were done in concert with OSGi. The OSGi community has joined the JSR 294 expert group and has tried hard to ensure alignment between the two, but at the end of the day it seems like Sun just wants to do what it wants to do.
Thanks,
Eric
Eric, I summarized my notes regarding Jigsaw at JavaOne this year in the following blog post;
ReplyDeleteClasspath hell just froze over
Mark's general session presentation did not mention OSGi, Alex's "Modularity in the Java Programming Language: JSR 294 and beyond" did not mention OSGi either. At one point he talked about how different version structures, order and ranges will be supported in order to accomodate other module systems, but I don't remember him mentioning OSGi by name.
Where OSGi was mentioned a lot was during the Jigsaw Q&A, my blog has more details, but most of the questions were on the native deployment and OSGi related issues (like why doesn't it use that instead of this new system). My characterization of the Q&A was that it got a bit tense at times, however I talked to Mark at the JavaFX party last Thursday and he didn't agree with my assesment of the meeting :-)
Augusto,
ReplyDeleteThanks for that, your blog is very detailed. I think the unfortunate truth of the matter is that despite strong efforts from the OSGi side, Sun has convinced itself that modularity is a feature it must redefine.
Therefore my opinion on why Jigsaw is a threat to modularity. It has the potential to delay progress on OSGi (in fact it already has since OSGi folks have been contributing to the JSR 294 work), fragment the marketplace, and cause a lot of confusion (such as what you express very well in your blog).
Sun is also kind of schizo on OSGi since they support it so strongly in Glassfish and OpenESB, and of course they also employ Richard Hall, the Apache Felix project lead. So I suppose you could say Project Jigsaw even has the potential to undermine Sun's investments in those projects.
From my point of view early on there was a lot of acknowledgment, at least verbally, from the Jigsaw team about the need to define a mapping for OSGi and ensure that the existing OSGi module system would work well with Jigsaw, for example through JSR 294. But in reality no one from Sun has ever done any work on this mapping, which means they are creating more issues rather than solving problems for developers.
I see Peter Kriens also replied to your blog entry on the OSGi blog.
http://www.osgi.org/blog/2009/06/classpath-hell-just-froze-over.html
Eric
JSR 294 is not a module system. JSR 294 has never been a module system. I go out of my way when talking about JSR 294 to be independent of module systems - Jigsaw and OSGi.
ReplyDeleteThe sum total of Jigsaw in my JavaOne talk on 294 was one slide showing how Jigsaw might use the 'provides' keyword, one slide expressing the concept that a compiler and a VM should talk to a module system (with Jigsaw as the example), and one slide of version examples. (Versioning is central to modular programming in Java, and all module system experts should welcome how its visibility is being raised through JSR 294.) Slides here.
What is extraordinary, Eric, is your claim that OSGi's progress has been delayed because OSGi folks have been contributing to JSR 294. I see no evidence that R4.2's schedule has been delayed because a handful of CPEG members attend a weekly one-hour 294 Expert Group call.
Moving on from 294, I note that the primary goal of modularity in JDK7 is to modularize JDK7 itself. There is much behind-the-scenes work to be done for that task. Ensuring that the OSGi and Jigsaw module systems can interact is on the agenda, but we cannot do everything at once. I have no doubt that modularizing such a large codebase as the JDK will provide lessons for both Jigsaw and OSGi.
Alex,
ReplyDeleteThe whole effort to create an alternate universe of modularity of course has an impact on OSGi. Any time OSGi folks spend on something other than R4.2 impacts the schedule. You would probably see this more clearly had you continued to participate in EEG meetings and calls. I deal with the problems your project creates for OSGi on a daily basis.
I think it is even more extraordinary that the Java modularity work is basically ignoring OSGi "for the moment" when so many lessons have already been learned.
It sounds like your goal is to relearn everything all over again.
Thanks,
Eric
Eric, germane to your comment is that I attended the CPEG meeting in Jan09, not the EEG meeting. I follow CPEG's activities; I am not a Java EE guy and cannot follow EEG with my other responsibilities. So within the CPEG realm, I would like to understand how JSR 294 has caused problems. I cannot see how 294 can be accused of ignoring OSGi when the EG has discussed and accepted the bulk of BJ and Peter's proposals (Bryan's too) on module-private accessibility.
ReplyDeleteIf you mean to say that the Jigsaw module system, rather than 294, is ignoring the lessons of OSGi, then again I would disagree. There is a wealth of information about OSGi's design and evolution available publicly and privately to Sun. As you say, we have great OSGi expertise in-house. But when the goals of the Jigsaw module system materially differ from those of OSGi - say, over the importance of dynamism - then it is inevitable that some of OSGi's lessons are moot.
Alex,
ReplyDeleteYour comments illustrate the problem. You attack and me defend JSR 294 on minor points but still offer no real answer to the major question: why did JSR 294 not start with OSGi?
Yes, you caught me! You attended a CPEG meeting, not an EEG meeting. We often have joint CPEG and EEG meetings, and I did mix up which one of the two expert groups you officially attended. But as you recall, we spent an entire morning discussing JSR 294 - time that otherwise could have been spent on the OSGi specification.
As in your previous comment about the impact on OSGi work -- You know as well as I do that attending calls is only a fraction of the effort involved to participate in an expert group. The email list has to be monitored, proposals studied and debated, and as we saw in the apparently wasted morning of CPEG (of which I'm also a member BTW) a lot of time simply understanding what's going on and trying to reach consensus on what to do.
Nonetheless, my original statement stands: if you were still participating in OSGi meetings you would be well aware of the impact of JSR 294 on OSGi.
The creation of an entirely new modular system is bad for the industry. There is still no good explanation as to why JSR 294 did not start with JSR 8 / JSR 291 (OSGi) as its base. Your comment mentions "material differences" between Jigsaw and OSGi but does not say what they are, nor do you explain why a new modularity system is necessary and the current one cannot be fixed or improved. When Jigsaw was announced, we saw more of the same "lip service" OSGi gets in your Java One presentation - the promise to work within the OSGi Alliance to map OSGi to JSR 294, and address within the existing modularity system any additional requirements, which are still not explained beyond the simplistic mention of the need for direct language support.
We can all understand and appreciate the benefits of incorporating modularity directly into the language, but we cannot understand the need to define a new modularity system (i.e. Jigsaw) to accomplish this goal. If it is necessary to propose changes to OSGi, you are a member of CPEG and well able to propose them.
Let's suppose the industry ends up with what JSR 294 proposes - a "meta module" system that maps both to Jigsaw and OSGi (despite the fact no meaningful work has been done to map OSGi).
How is it possibly a good thing for everyone that the thousands of products and technologies already modularized will have to be refactored for the new system?
How is it possibly a good thing for the industry that Java Modules can be defined using two alternative and incopatible modularity systems? The whole idea of modularity is to be able to break apart programs and easily combine them.
Yes, OSGi folks indeed participate on the JSR 294 expert group, but that does not mean they endorse the result, or that their input has been adopted. I have been following the public email list closely enough to observe that much at least.
And on the point of versioning - yes this is indeed important but OSGi already supports it, and again if there is some defect or change needed to this, it would be much more sensible to propose it within the context of OSGi than use it as a justification to create an entirely new and incompatible modularity system.
Eric
We did NOT spend an entire morning discussing 294. We spent exactly one hour (8.30am-9.30am) discussing the Jigsaw module system. As you will recall, I was treated abominably. I debate excitable individuals on the Java programming language all the time, and have never experienced such a verbal mugging as I encountered in CPEG. Nevertheless, I follow the CPEG list via the Web archive and there is no discussion of 294 or Jigsaw after January, so your claim about wasting time doesn't stand up.
ReplyDeleteJSR 294 doesn't propose a meta-module system. There was a proposal from one EG member discussed at the face-to-face meeting for a module system API. Two outcomes of that meeting were that a) the proposal was too big for 294 to handle in the JDK7 timeframe, and b) the existing Sun proposal for an API to support OSGi's favorite feature, module-private accessibility, is too complex. Again, I bend over backwards to accommodate the EG's views.
Finally, I didn't mention versioning and it is really the least of my worries about the OSGi module system. The abstractions in OSGi to support dynamism, a complete non-goal for Jigsaw, are more at issue. Adding some of Jigsaw's features to OSGi would be like adding the Java type system to Ruby; technically possible, sure, but a complete mess.
Hi guys,
ReplyDeleteI just wanted to point your attention to Project Penrose: http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html
It's proposal is to bring OSGi implementors together with Project Jigsaw. The funny thing about that is, that it just mentions OSGi implementations and not the OSGi Alliance itself.
Regards,
Benedikt