Alex headshot

AlBlue’s Blog

Macs, Modularity and More

EclipseCon roundup

2009, conference, eclipse, eclipsecon

This year’s EclipseCon has drawn to a close, so what happened on the last day, and what were the overall takeaways from this year’s conference?

Keynote

Tim Wagner and Kevin McGuire gave us a memorable delivery of “Darwin amongst the IDEs” as a scripted/acted discussion between two people over a coffee. The context of the presentation was evolution; screenshots of Eclipse 1.0 and comparable Visual Studio products were shown and compared with current versions of the same. Mostly, the UI metaphor for software development hasn’t changed (although the screenshot of the IDE of the future, with an XVGA sized editor surrounded by plentiful window buttons certainly gave the audience a laugh).

The point of the presentation was really one of inertia having set in with the Eclipse UI. Nature long ago tried what worked (and a whole lot of things that didn’t) but as the environment changes, new niches can appear and other ways of achieving existing goals may be met by other ways. One such event occurred when Eclipse JDT was released in 2001 – before then, commercial vendors were selling largely incompatible development tools (Borland’s JBuilder, Symantec’s Visual Café, IBM’s Visual Age). But by moving to a common denominator, the ecosystem for plugins opened up with the result that there’s many more possibilities even though commercial tools upon Eclipse still thrive. In addition, the Eclipse ecosystem space now inhabits places where the original product intention was never meant to tread; remotely editing files, debugging on hardware devices, scheduling time on the NASA Mars rovers etc.

However, even with the exploitation of the ecosystem, we’re still doing development much the same way as in the Visual Café days. Yet the processing systems of the average smartphone probably exceed those of computers at the turn of the millennium; and for the most part, the computer’s CPU goes by idly (as I write this, the computer’s CPU is idling along at 80% whilst I have an Eclipse and XCode in the background). About the only big event in Eclipse is the introduction of Mylyn, which allows for context-based filtering of the current working set to reduce the amount of data shown on the screen. That, too, has resulted in its own mini-ecosystem of connectors to different task tracking systems; and companies like TaskTop extend that same capability to day-to-day office environments like mail and calendaring.

The keynote asserted that you need to evolve to survive (though personally, I don’t think that’s necessarily true; it may be worth exploring other avenues, but the original can go on existing for a long time to come). The whole presentation, whilst well delivered, felt like it was lacking in substance, and perhaps more a call to arms (or justification?) for E4, slated to be released in 2010. Various presentations have been keen to point out that the 3.x stream will continue to be supported for some time to come, but as with other comments in the previous two days, E4 is here to stay.

Jetty at Eclipse

Greg Wilkins of Webtide gave a presentation on Jetty’s migration to Eclipse; what it means, and what it doesn’t mean (which I covered at InfoQ earlier). Jetty has been OSGi-enabled, and in doing so, cleaned up some odd dependencies (such as the Jetty client JAR depending on the server JAR) as well as a refactoring of the namespace to org.eclipse.jetty. The core components are now hosed at www.eclipse.org/jetty and development of the Jetty 7 codebase is now at Eclipse, under a dual EPL and Apache License. However, additional features, connectors and other extensions/examples not conducive to the EPL continue to be located at CodeHaus. Webtide will continue to make releases of Jetty available and provide commercial support.

Using OSGi’s module layer to enforce cleaner separation is one of the benefits you get from using OSGi modules; however, as OSGi modules are just JARs with extra manifest information, they can continue to be used in non-OSGi aware applications merely by adding to the classpath. It’s a great example of how public libraries are starting to become more OSGi friendly whilst still not necessarily depending on OSGi itself.

Greg also touched on other aspects of Jetty which were new to me; as well as the traditional blocking servlet requests, Jetty supports asynchronous requests (both client and server side). In this case, the data comes back at a later point (and maybe via a different thread) from the original request. A few years ago, this might have been seen as an odd way of doing things, but really it shows that the way in which systems work needs to be much more focussed on such asynchronous behaviour. JavaScript’s asynchronousity is a given from the AJAX behaviour given by XMLHttpRequest, and this pattern seems to be commonly understood where before the Web 2.0 bubble it perhaps wasn’t. In any case, Greg demo’d a system scaling to 2,000 clients and 2,000 servers sending messages at the rate of 2,000 a second using asynchronous access.

The other focus point on Greg’s presentation was the footprint of Jetty as an embedded system. Since it’s used as a communication engine in Hadoop, and Yahoo has 130,000+ Hadoop nodes, then even a few extra bytes here and there can translate into serious memory requirements, so at both the low and high ends of the computing spectrum, memory is at a key. Jetty even handles its own UTF-8 processing since it can share buffers between lower and higher levels.

It’s hoped that the move to Eclipse will increase the publicity for both and that there will be more tie-ins with OSGi, such as updating OSGi’s HttpService which is based on an older version of the Servlet spec. Jetty 7 is planned for 2009Q2 and Jetty 8 (on the Servlet 3.0 spec) in 2010Q1.

Conference wrap-up

EclipseCon is still a vibrant conference in the face of economic cutbacks, and whilst the turnout for the event was smaller than previous years that I’ve attended, there were still around a thousand attendees. The reduced size meant less blog entries written during the conference itself (also possibly because the bloggers were going to more talks) but in addition, the use of the #eclipsecon twitter search keyword, organised by Ian Skerret. Close to one in four people followed the twitter updates, and a fair number tweeted from the conference (Robert Konigsberg provided a breakdown of the tweeters). This alternative mechanism somewhat reduced pressure for people to blog about; either way, it’s a mechanism for those that weren’t able to be at the conference to follow some idea of what was going on.

The future of conferences has been questioned recently, with cutbacks and travel budgets slashed in recent months. A number, but not all, of the EclipseCon presentations are available at the gPublication server, including previous years, and there’s even a button you can use to download the presentation as a PDF if you know where to find it on the hideous Flash interface. And given you can follow the tweets, why would you want to attend? Well, not every presentation is available (especially the keynotes) and the tutorials are definitely beneficial to attend if you want to learn a technology. But the chance to network – whether as people interested in job hunting, suppliers looking for potential customers, or even hooking up with past family and friends of Eclipse, meeting in person at the conference (or the bar after) is the way to do it. That might in itself not be a reason you can argue with your boss, but it’s the key benefit you get from being there, and I think with the on-going success of OSGi and Eclipse it’ll be happening for a few years to come. (It will be interesting to see what happens to Sun over the next few months since a lot of Eclipse is stacked in Java’s direction.)

This is also the first year I attended EclipseCon where there wasn’t any JDT-related presentations (well, one demonstrating Aspects to enhance the JDT). From conversations at EclipseCon, it seems that the JDT is ‘done’ and has no further work planned; not the least of which is that there (at the moment) no new language features to implement. It’s not unsupported – there are still a couple of people working on bugfixes and the like – but there’s Eclipse JDT commits been a drop-off in commits over the last year. Whether this is because of a planned maintenance mode or simply a movement of funded resources to other projects (like E4) is somewhat speculation, but it does seem that the work on JDT is slowing down. Having said that, there’s not much that the JDT can’t/doesn’t do (with the exception of parallel builds, though the JDT compiler can compile a single project in parallel).

The takeaways for this year’s EclipseCon were really focussed on the runtime aspects of Eclipse; from the breadth of OSGi presentations (including those running in cloud and ESB infrastructures) to clients upon that runtime (Jetty), a lot of the Eclipse namesake is being associated with the runtime platform than the IDE. A lot of code exists in E4, and the demonstration of the in-web browser editor Bespin (and having the Bespin back-end in E4 already) shows that there’s a lot of cool ideas in the pipeline. Like the presentation suggested, it’s not clear that there’s always a winner at this stage of the game but E4 is an ecological gamble that there may be more than one way to solve the problem.

Distributed version control really reached tipping point at this year’s EclipseCon, with the bug 257706 discussing Git at Eclipse and the draft EGit proposal that’s currently in process. Over the coming year, I’d expect to see some progress in getting an EGit plugin available for Eclipse up and running, with it being offered for download with a main bundle at some point in the future. It’ll take some time for it to usurp existing projects, though some will jump on it earlier than others.

There’s still a long way to go to convince Java developers (particularly those who use other IDEs than Eclipse JDT) that OSGi is the way forward, but Spring and other high use technologies are really showing the way forward. What’s really needed is some kind of generic build platform for OSGi bundles that’s non-Eclipse specific – such as sigil or maven-bundle-plugin will make it easier for developers to build and craft OSGi bundles outside of the familiar PDE environment, which has some pretty serious limitations if you want to do your own thing (like requiring that the META-INF is at the top-level of your project, for example). That’s one of the main limiting factors against more widespread OSGi adoption at the current time.

Here’s looking forward to the next EclipseCon!