Archive for October 2010
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!
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.
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.
Thanks to the Program Chair, Bernd Kolb of SAP and his hard-working Program Committee, this year’s ESE promises to be the best ever. The keynotes alone are going to be hard to beat. In order of appearance we have:
- Dr. Hendrik Speck (University of Applied Sciences Kaiserslautern) on “Code and Belief“. I saw Dr. Speck speak at an event in Berlin a few months ago and thought his talk was extremely thought provoking.
- Dr. Jeff Norris (NASA) on “Mission-Critical Agility” will reprise his incredible talk from EclipseCon 2010 — one of the best talks I have ever seen.
- Dr. Gunter Dueck (IBM) on “The Industrialization of the Services Sector“. I haven’t had the opportunity to see Dr. Dueck speak before, but I’ve heard from several people that he is excellent as well.
In addition, the main technical program has something in it for every budding Eclipse aficionado. There are five tracks, all of which are offering two full days of great talks: Eclipse 4.0 (e4), Embedded, Modeling, Runtime and Other / New & Noteworthy.
Putting on events and conferences is a large part of what we do at the Eclipse Foundation. They are a ton of work, but are absolutely worth it in every way. Each event provides an opportunity for our worldwide community to come together, meet, talk and maybe have a couple of beers. So register now. I find ESE in particular to be a great community event: great technical content with a relaxed and cool vibe. I really hope to see you there!
Oh, and thanks to all of our sponsors! We literally could not do it without you.
Today’s announcement that IBM is going to join forces and work with Oracle on OpenJDK is good news for Java, and by extension for Eclipse. All of us who live within the Java ecosystem need to recognize that this fundamentally strengthens the platform, enhances the business value of Java and offers the hope of an increased pace of innovation.
Although it will take a while for all of the ramifications and reactions to become clear, at its face the announcement challenges the conventional wisdom that the future of Java is going to be a fractured one. Some recent examples of these expectations can be seen in blog posts like James Governor’s “Java: The Unipolar Moment, On distributed governance for distributed software” and Joseph Ottinger’s “The Future of Java: forking, death, or stasis”. When I read them just a short time ago, I thought they accurately reflected the likeliest outcomes for Java’s sure-to-be fractious future. Now I am much more optimistic that we can get back to innovation.
To me the overarching motivation is obvious. Both IBM and Oracle have a shared interest in assuring their enterprise customers that Java was, is and always will be the safe technology choice that they’ve been selling for the past ten to fifteen years. As much fun and excitement as a further escalation of the “Java Wars” would have been, both companies have a very large vested business interest in combining forces, closing ranks and focusing on reassuring their customers that Java should remain their platform of choice.
This announcement fundamentally alters the equation in at least three important ways.
- The presumption of conflict: Implicit in almost all of the recent writings on the future of Java is the notion that IBM’s interests would lie in direct competition, if not outright conflict with Oracle’s. Many have been assuming that IBM would eventually snap and declare war on Oracle’s Java hegemony, with the battles being fought in places like OSGi, Apache and Eclipse. It is now apparent that is not going to happen. Furthermore, now that IBM is working with Oracle on OpenJDK, we can expect a lot more mutual support within the JCP on driving specifications, especially platform specifications, forward.
- Oracle is focused on reviving the business of Java: In case you hadn’t noticed, Oracle’s stewardship of Java is going to be a significant departure from Sun’s. As Amy Fowler said “…this is a practical company who isn’t suffering from an identity crisis and knows how to make money from software.” A couple of thoughts on the differences: First and foremost Oracle actually has resources to invest in moving Java forward, whereas Sun’s financial weakness prevented forward progress for at least the past three years. Second, Oracle is putting in place the software engineering discipline and process in place to ensure that future releases of Java can happen on a much more reliable and predictable timetable than Sun. Third, Oracle is large enough and confident enough in its execution that it is much more comfortable in striking business deals with its co-opetition such as IBM. It will be darn interesting to see if they are successful in signing up more participants down the road. And finally, there will be less talk about community-driven motivations and more focus on the business.
In my opinion, all but the last of those are unequivocally positive. But Oracle’s current focus on the business at least offers the hope that it may pay community dividends down the road. It is a lot easier for large companies to consider community motivations when they’re profitable and feel that they have momentum on their side. The past couple of years of Java have been years of stalemate, lack of innovation and lost opportunities. Turning that around has to be job one if Oracle is going to see a return on its acquisition.
- This is an inflection point in the Oracle-IBM relationship: If you think back a few years ago, IBM and BEA were two companies who competed fiercely in the Java marketplace, but managed to collaborate on many JCP specifications and in numerous open source projects at places such as Apache and Eclipse. It was a mature industry relationship. Maybe I’ve missed it, but I haven’t seen a similar historical pattern with IBM and Oracle, even after Oracle acquired BEA. This is an important step in the relationship between the two companies, at least in the Java space. Hopefully it is a harbinger of additional collaboration.
The big question is what are going to be the reactions of the other significant players in the Java ecosystem. The actions of Google, SAP and VMware in particular will all be interesting to watch.
Disclaimer: Both IBM and Oracle are Strategic Developer Members of the Eclipse Foundation, with seats on our board of directors. They are first and second place respectively in terms of the number of active committers contributing to Eclipse projects. SAP is also a Strategic Developer Member. Google, VMware are Solutions Members of the Eclipse Foundation.