Introducing Orion
Sometime later today some very exciting new code is going to show up in the e4 git repository at Eclipse. “Orion” is a brand new adventure for Eclipse, and one which we hope will interest and excite a whole new community: web developers.
Orion is not a set of Java plug-ins which run in the existing Java IDE. It is browser-based open tool integration platform which is entirely focused on developing for the web, in the web. Tools are written in JavaScript and run in the browser. Unlike other attempts at creating browser-based development tools, this is not an IDE running in a single tab. Links work and can be shared. You can open a file in a new tab. Great care has been taken to provide a web experience for development.
Orion’s server-side is currently a simple OSGi-based Java application using Jetty as its web container. But the communication with the client is through a fairly simply RESTful interface, and we definitely hope to see implementations in other languages and technologies.
I cannot emphasize strongly enough that this is not the same old same old from Eclipse. Orion is a new code base, whose client-side is written in JavaScript and provides the foundation for a new and different web tooling platform. We hope that a new ecosystem of web tools will emerge that make it easy to link together a web developer’s toolset.
Another key point is that Orion is not finished. It is not, for example, a complete JavaScript IDE. This is the very beginning of a new project, and everyone involved knows that we have a lot to learn. Unlike the early days of the Eclipse project itself, the team from IBM is contributing a relatively modest — but very useful — piece of code to spur the creation of whole new community of contribution and participation. We invite everyone who is interested to try the code, join the mailing lists and forums, and figure out ways to both adopt and contribute to the work that has been done. Even more importantly, we are looking for people and organizations to get engaged in Orion in meaningful leadership roles for everything from adding code to defining the project to prioritizing the roadmap. We know that this needs to be a community-led process.
The team is going to be blogging about the details of the technology, so I won’t steal their thunder. But hopefully the screen shots will spur your interest. Certainly we think there is a very interesting and highly scalable editor tool which a lot of web developers are going to be interested in both using for their code and embedding in their applications. Update – you can now download the Orion code.
So today is the very beginning of something new. But there is a lot of work to do, and first and foremost we need you the community to provide feedback and to get involved. For those who can make it, we are going to have a face-to-face meeting in Ottawa the first week of March to discuss where we can collectively take Orion. The output of this meeting will be a first draft of a project proposal for the community to review.
So to set expectations, here are a few key dates to keep in mind.
- This week we are going to get the initial code contribution into Eclipse’s git repository and some initial documentation into the wiki.
- Next week we are going to start inviting a small number of people to try out the technology hosted on our servers.
- By the end of January we will have a much broader trial available on our servers, and we will be inviting the entire Eclipse committer population to try it out.
We are awfully excited about the potential of the work done to date. Stay tuned!
Update: Changed the screen shots to show the Orion wordmark, rather than Eclipse.
Update: Added links to the wiki pages and Boris Bokowski’s blog post.
Christmas Comes Early for Java Developers
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!
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!
Life at Eclipse 