Barb Moving On
I have a bit of sad news, which is that Barb Cochrane of the Intellectual Property Management team is leaving us, effective Friday. Barb has been great to work with for the past three years. She added a lot of fun and enthusiasm to both the office and the community, and was incredibly diligent and professional in her work. A great combination! She will definitely be missed by all of us at Eclipse.
After talking with Janet Campbell, we’ve decided that for at least the next few months we’re not going to replace Barb’s position. The tasks of recruiting and training a replacement would only slow the team down further as we head into the busiest time of the year for IP reviews. For projects which are part of the Indigo release train we highly recommend getting your CQs in earlier rather than later, carefully considering whether you truly need to packages you’re asking for, and be darn sure you make it clear that you need the CQ for Indigo. Janet will be communicating deadlines and progress through the normal channels as we get ready for the release train.
So Barb: so long and thanks for all the shwarma!
Qualified Support
Neil Bartlett asked me on Twitter a few days ago why the Eclipse Foundation was supporting the JSR for SE8, given that this JSR is “anti-OSGi”. That is a very good question.
I believe that Neil and others are basing their “anti-OSGi” read of the JSR based on Section 2.1’s description of modularity. “OSGi already does this” being the operative phrase. Of course, OSGi already does this stuff and could easily be the solution for the set of described requirements. However, I also believe that if you read the section purely from the perspective of the status quo which exists today for the JDK, all of the statements there are perfectly valid. The point made in Section 2.5 illustrates this further: “Existing [modularity] frameworks and tools support these tasks today, but standardization in the Java SE Platform would promote interoperability and benefit developers, users, and vendors.”
But the statement in the JSR which ultimately drew our support is in Section 3 (emphasis mine):
In the case of the proposed Java Platform Module System JSR, it is understood that there is already a significant investment within the Java community in applications and frameworks built using the module layer of the OSGi Service Platform. The extent to which the Java Platform Module System should adopt, interoperate with, or otherwise accommodate OSGi will be a topic for that JSR’s Expert Group and the Java SE 8 Expert Group to discuss and decide.
The bottom line is that this JSR (well actually the still-to-be-established JSR focused on modularity) represents the beginning of a conversation about the shape of modularity in the base Java platform. This conversation is going to take something on the order of one or two years to complete. We are supporting this JSR because it is the forum for that discussion. But if the end result is “anti-OSGi”, I’ve already made it clear that we will be voting against it. And although no one else has publically committed to a position, I think we will be in good company in doing so.
I should also be clear on what I mean by anti-OSGi. I haven’t spent a ton of time thinking about this, but at the moment my perspective is that the bottom line is the existing OSGi ecosystem must be able to continue operating on SE8 without any interruption. Further, OSGi cannot be disadvantaged by platform modularity in terms of performance or scalability. But I have heard enough comments from very competent Java developers who are unhappy with OSGi that I don’t believe that in its current form it is perfection personified. So perhaps there will be options along the lines revisions to OSGi specs, an inter-operability story or some other solution beyond the scope of my imagination or technical abilities. So “anti” does not equal “use OSGi in its current form or else” in my view.
I am not so naive as to think that this is going to be easy. Mark Reinhold and others at Oracle have made it pretty clear that OSGi in its current form is not the solution that matches their vision for platform modularity. To change this is going to require persuasion on both the technical and ecosystem/business benefits of OSGi. I use the word “persuasion” very consciously because I believe that the name calling and negative emotion which have been part of the modularity debates (on both sides) over the past couple of years have not, in my view, been helpful. We (the OSGi) community have one last kick at this can. This is it.
Take a Deep Breath, Then Vote for Eclipse: Our View on the JCP
My goodness, this past week has seen a flurry of despair around Java and the JCP. Most of it misguided, in my humble opinion. Matt Asay’s article does a good job of capturing all of the angst in one spot. If you haven’t read it, I recommend that you do even though I disagree with much of it.
Let me start by saying that like Red Hat’s Bill Burke, I believe that Java and the JCP are doing just fine and are here to stay. Despite some short-term growing pains, they are both in much better shape than they were under Sun’s stewardship over the past couple of years. In fact, I would go so far as to say that in terms of real, tangible progress, this past month has been the best for Java in the past three years.
I should also say that this post is focused on the issues that pertain to Java SE and EE, which is the Executive Committee that the Eclipse Foundation is running for. The concerns which are impacting the Java ME ecosystem will be for another post on another day.
There is one thing that Matt, Ian Skerrett and others have gotten exactly right: the failure to communicate effectively with the Java community is costing Oracle dearly. They have got to fix that, and soon. The problem is that Oracle has always been an enterprise software company, with PR and AR people who think that controlling the message is the path to success. Oracle as an organization has a lot of internal institutional challenges to overcome before they can learn how to communicate with a community like Java’s. It will take time and there will be mistakes along the way, but I think they will. They have to, because as we have recently observed, silence is significantly worse than delivering even bad news in a clear and honest manner.
So let’s examine some of the recent commentary.
- “The Great War of Java”: Stephen Colebourne’s most recent post is, well, just plain wrong. I totally understand the frustration and disappointment of the Apache community who have done so much for Java over the past decade or more. But the fact is that the “Great War of Java” didn’t happen, and it well could have. The announcement that IBM had made peace with Oracle and was joining OpenJDK meant that the fork that so many had predicted is not going to happen. I cannot say this strongly enough: characterizing the current status quo as a war is just wrong. What we may have on our hands is a failure to communicate, a major disappointment for Apache and/or a time of significant change in Java’s governance. But in my opinion the conflict that truly could have harmed Java has been averted.
- Doug Lea’s departure from the JCP EC: Doug has been a very important voice on the JCP Executive Committee since long before we got there. He understands the process deeply and cares about how players other than the large corporations can participate, contribute and innovate within the Java ecosystem. He will be missed. However, I do think that his reasons for resigning were based on some incorrect assumptions.
I believe that many people are confusing the JCP’s vendor neutrality with its effectiveness as a specifications organization. The JCP has never and will never be a vendor-neutral organization (a la Apache and Eclipse), and anyone who thought it so was fooling themselves. But it has been effective, and I believe that it will be effective again. That’s why if re-elected, Eclipse will be voting for the Java 7 JSR. We need to get back to actually getting platform specs through the process if Java is going to advance.
As a truly vendor-neutral organization, we at Eclipse understand the value that brings to the community and the commercial ecosystem. Unfortunately, I believe that OpenJDK’s governance will, in the end, be no more vendor-neutral than the JCP’s. It simply cannot be. Oracle has a responsibility to its commercial Java licensors to deliver them intellectual property under commercial terms and conditions, which is why contributors need to sign the CLA. By definition, if Oracle needs to own the IP for Java, including the IP in OpenJDK, the governance model will always require some sort of special role for Oracle. I wish it could be otherwise, but that is how I see the situation.
But the key point is that in neither case (JCP or OpenJDK) does the lack of vendor neutrality mean that the organizations are ineffective. Both have already demonstrated success in pulling together many competing interests and getting innovative work completed. So the lack of vendor neutrality is not fatal. In fact, I am optimistic that having both an open standards and an open source organization working in collaboration will help accelerate innovation in the Java platform.
- Apple’s deprecation of Java:The simple fact of the matter is that none of us yet know exactly what this means, or why Apple took this approach. Steve Job’s explanation was particularly lame. If release cycle alignment was a fatal problem, none of the platform vendors would still be shipping Java. I am a bit of a cynical sort, so my hypothesis is that this may simply be a contract negotiation ploy. If Apple wanted to put pressure on Oracle for a better Java licensing deal, wouldn’t this be a fairly obvious way to do so?
But I do believe that Apple may have under-estimated the negative implications for their own business. Not shipping Java on the Mac has obvious implications for Java developers. Everyone who uses IntelliJ, NetBeans and Eclipse will be impacted at some level. But one aspect that I have yet seen discussed much are the implications for other language developers. Don’t forget that the leading development tools for Android, PHP and Adobe Flash (to name just a few) are all based on Eclipse as well. I have to wonder if Apple has thought through how many developer communities they will be alienating if they push this no-Java stance too far. I predict a mid-course correction.
- Use the OSGi Alliance instead: A few people have suggested that if the wheels are going to fall off the JCP, perhaps the OSGi Alliance can step into the vacuum and become the leading specification organization within the larger Java ecosystem. Despite Eclipse’s commitment to OSGi, I have to say that there is asymptotically close to zero probability of that ever happening. The reason is simple: IBM, Oracle, Red Hat and others are committed to making OpenJDK and the JCP successful, so there is no vacuum to fill. I would say to our friends at the OSGi Alliance that this conjecture is neither realistic nor helpful.
It is clear that Java is going though a period of turmoil. But anyone who has gone through a large corporate acquisition could have predicted that some amount of chaos was entirely predictable. The Eclipse Foundation is committed to the success of both Java and the JCP, and we are optimistic that the JCP will remain a highly effective specification organization for the Java community and ecosystem. I hope that you will vote for us in the on-going election!
Java 8 Vote
Yesterday I described the reasons why I think the Eclipse Foundation should vote in favour of the Java 7 JSR when it is proposed. We are no where near as positive about the Java 8 JSR.
The reason is modularity. We are just not comfortable that the direction of the Java 8 team will do an adequate job of bridging the divide between the OSGi world and whatever modularity model is decided upon for the platform. Which potentially means that Java 8 may ship in late 2012 (actually I predict early-to-mid-2013) with a modularity model which is orthogonal to, and incompatible with OSGi. In our opinion, that would be a disaster for the Java platform and the Java ecosystem.
Let’s recap just a few of the reasons why OSGi is important to both Java and Eclipse:
- OSGi forms the basis of the Eclipse plug-in model used by millions of Java developers. The Eclipse Equinox and Eclipse Gemini projects provide the reference implementations of quite a few of the OSGi RFC’s.
- OSGi is used by many of the Enterprise Service Bus (ESB) implementations out there.
- OSGi is used by almost all of the major Java EE application server implementations, including oddly enough Oracle’s WebLogic and Glassfish products.
I am not saying that OSGi is a panacea. There are lots of people out there who will happily tell you about all of the reasons why it is imperfect. For example, despite the fact that its roots are in embedded, it objectively has been a failure in the Java ME space. My point is that it is deeply ingrained in the Java ecosystem and in the architectures of many of the most successful Java products out there. I cannot imagine a scenario where ignoring or trying to replace it in a major Java platform release two and a half years from now can be anything other than a train wreck.
I would be awfully happy to be wrong, but my perception is that the Java 8 JSR is looking at modularity as a greenfield project where they need to arrive some sort of perfect solution, with no historical constraints. We, on the other hand, believe that: (a) there is an incumbent technology that must be accommodated and (b) the problem we collectively face is not software but social engineering. In the best interest of the Java community, some sort of compromise is going to be required.
The JCP is setup to mediate these types of technology decisions. The potential disagreement around Java 8 JSR is a technical issue, not a contract issue as is Java 7 JSR. Unless we see sufficient accommodation for OSGi in the Java 8 JSR we will be voting No.
Java 7 Vote
Stephen Colebourne correctly pointed out in his blog this morning that when the Java 7 JSR is proposed to the JCP Executive Committee, that the Eclipse Foundation will vote “yes”. I think that it would be helpful to explain why that is the case.
First, some history. The Eclipse Foundation has been on the JCP EC for three years. The dispute between Apache and Sun (now Oracle) regarding proposed field-of-use (FOU) restrictions placed on Apache Harmony predates our tenure. At every opportunity during those three years we have supported Apache’s position, including explaining to corporate representatives why this is such a big deal for an open source community. We agree that Apache Harmony should have received an unencumbered TCK license and our votes consistently supported various resolutions on this matter.
However, the time has come to move on.
For over three years now, Java has been stagnating as a language and a platform. As I said a few days ago, they “…have been years of stalemate, lack of innovation and lost opportunities.” At some point this lack of progress becomes an existential question. If Java does not start to progress as a platform, it will die. It has already suffered an enormous loss of momentum.
It is really important to understand that the JCP EC does not have the power to grant Apache a TCK license, only Oracle can do that. If the JCP had the power, Apache would have had their TCK years ago. So at its essence, this is a contract dispute between the Apache Software Foundation and Sun Microsystems (now Oracle). There are only three ways that this intractable dispute can be resolved:
- Oracle caves. Well, we all know that’s not going to happen. Sun did not cave for three years, and Oracle has made it abundantly clear that they’re not going to. If IBM couldn’t find some leverage, I don’t see how the open source communities will.
- Apache sues. Even if Apache had the resources, I am guessing their legal counsel would advise against it. Lawsuits are legal warfare, with all of the potential for unintended consequences and collateral damage that statement implies.
- We move on. Realistically, this is the only option left. As much as continuing the fight appeals to the heart I cannot see how this dispute will ever reach closure. Although I certainly understand the natural inclination to want to continue the struggle against the slings and arrows of corporate behaviour, I just honestly believe that at this point it is beyond reasonableness to do so.
Note that our position is not making any assumptions about the future of Apache Harmony. Hopefully others will step in and carry the project forward. But that is not an argument for continuing the impasse blocking the future of the Java platform.
Therefore, we are going to vote based on the technical merits of Java 7. From our point of view “Plan B” defines the logical next steps for the Java platform. Java 8 is a different story and left for another blog post.