Life at Eclipse

Today Google announced that they will be contributing two key pieces of Java tooling technology to proposed Eclipse Foundation projects. Two new projects are bringing to Eclipse product-quality code which have been highly regarded by Java developers for many years. They will fill major requirements that the Eclipse developer community have been hoping to see in open source for a long time. The WindowBuilder project will be led by Eric Clayberg of Google and Pavel Petrochenko of OnPositive Technologies will lead the Runtime Analysis Tools (RAT) project.

WindowBuilder is one of the best Java GUI builders out there. It supports both SWT and Swing and is fully bi-directional, meaning that you can work on the code or the visual design – it’s your choice. Just as importantly, the architecture is extensible so the team hopes to see additional designers built on top. Part of the goal here will be to hopefully create an ecosystem of open source and commercial extensions that make use of WindowBuilder’s core functionality to create GUI designers, as Google plans to do with its GWT Designer offering. [Update] Google already has a great start at creating community around this project by welcoming committers and contributions from Genuitec (Swing and mobile tools), compeople(Riena support) and Cloudsmith (data binding support).

CodePro Profiler is an excellent Java application profiling tool, and forms the basis for the code contribution to RAT. The profiler supports Java developers to inspect the running applications, find performance bottlenecks, detect memory leaks and solve problems regarding thread concurrency in your Java applications. Great Java application profiling is something that Eclipse users have wanted for years, and soon it will be here.

Both projects intend to join the Indigo release train in June 2011. It will be a lot of work for the teams, but having these projects available so quickly will be great for Java developers who use Eclipse. I know that the teams are very interested in growing community participation, so if you can help please join in on the conversation on the Proposals forum.

Google has been a big supporter of Eclipse for years. They are a long-time Solutions Member of the Eclipse Foundation, last year they provided an additional $20,000 to us to improve the server infrastructure for our projects, they provide the hosting for Eclipse Labs, they support us in the Google Summer of Code and they run the Eclipse Day at the Googleplex each year. But this is the first major code contribution to the Eclipse community from Google. I hope you will join me in thanking Google for making this happen!

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!

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:

1. 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.
2. 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.
3. 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.