The geeks have it ...

You voted, and the ThinkGeek 8-bit Tie won this year's EclipseCon tie-of-the-week contest. Thanks to all that voted and see you next year!

EclipseCon roundup

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 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!

EclipseCon Day 2 in review

The biggest surprise news of EclipseCon day 2 was Amazon's announcement of the AWS Toolkit for Eclipse, a set of bundles for instantiating, managing and remotely deploying and debugging on Eclipse instances running in the EC2 cloud. (The source is currently aws-eclipse on SourceForge under an Apache license.)

Keynote The keynote was "Building Applications for the Cloud with Amazon", and whilst very Amazon-specific did touch on cloud-computing. Some of the numeric figures were pretty amazing; there was 40 billion S3 objects in 2008 (up from 1 billion in 2006) so the growth is pretty phenomenal. In fact, 2007 saw the tipping point between bandwidth consumed by Amazon and bandwidth consumed by all other AWS customers, with AWS racing ahead in terms of usage.

One claimed benefit of cloud computing is the ability to elastically scale with the demand; this was demonstrated with an advertising push from Animoto which bases its back-end on EC2, and needed to scale up from an approximate 40 instances to 5000 instances after a particularly successful advertising campaign on Facebook - all over a four day period. Good luck getting a purchase order approved for another 4900 computers to be ready in a couple of days in your own company!

The other aspect of flexibility is the decoupling between usage costs and ownership/maintenance/cooling/power costs. Although this has benefits for tax implications, the main one is the speed in which the servers can be acquired and utilised. The other author of the talk, from SmugMug, noted that at one point, their auto-scaling system inadvertently started 250 instances. (More recently, Amazon has allowed large-scale customers to block-book instances which makes it more efficient from a resource scheduling perspective.)

Where does this fit with Eclipse? Well, E4 is becoming more pervasive, and technologies like RAP already have server-side components that need to run on back end hardware. It's pretty clear that there are advantages (but that doesn't mean it's relevant for everybody) in the cloud computing world. I suspect a certain amount of new approaches to existing problems are likely to evolve using the cloud in the future.

The question immediately following Amazon's announcement was whether this could be used for Equinox or OSGi based applications. As luck would have it, Aleksey Aristov discussed this on day 3, and demonstrated a soon-to-be-free or open source Cloud Shield/Studio (name yet to be determined) which did exactly that. Using a customised Amazon instance, and an SSH tunnel, it was possible to bring up an Equinox app and provision it on the fly to start a remote OSGi engine. Together with OSGi's new Framework starting technology, it's quite likely that we'll see a few of these kind of approaches coming together for different kinds of cloud services; but at the moment, it's at the early adopter stage. By next year, I fully expect to see more demonstrations of this, possibly even from the E4 fallout.

OSGi Although the OSGi 4.2 draft specification was released earlier in the week, I haven't had much time to dig into it. However, there was an overview of a few services which are particularly noteworthy here which were covered in a couple of talks. Note that the OSGi 4.2 is currently an draft release and is subject to change

• Blueprint service Costin Leau of SpringSource presented the Blueprint service for OSGi, which allows code to participate in an OSGi environment by being dynamically wired up to services without dependencies on the OSGi APIs. Anyone familiar with Spring will understand this Spring pattern immediately; the blueprint service is essentially a renamed version of the same (for trademark reasons). Although it's possible to mix-and-match these separately, chances are that Spring developers will continue to use the Spring namespaces/configuration and vanilla OSGi developers will use the OSGi specification. Either way, it allows a simpler way of wiring up services without having a dependency on OSGi code, which may be a benefit for testing or other circumstances where a dual OSGi-and-non-OSGi approach is used.

• Framework launching Richard Hall (Felix fame) and Thomas Watson (Equinox fame) discussed Framework launching in OSGi. In essence, this standardises the way that an OSGi framework is launched, which will make it easier to have shell scripts that bring up a platform based on some kind of external configuration parameter (as well as standardising on some of the property names required for various configurations). Pax Runner already solved this problem of bringing up instances, but this extends the concept to provide a standard programmatic API. One of the neat aspects to this is that it should allow a normal Java program to bring up an OSGi instance and auto-instantiate the correct framework on the classpath. Anyone who embeds an OSGi engine might find this useful, or allow things like the ServletBridge to be more Equinox agnostic. A neat solution is that the Framework interface now implements the Bundle interface (for accessing the bundle context etc.) so that API will already be familiar to new users. It also leads to:

• Composite bundles These allow a set of bundles to be treated as an independent (versioned) unit. In essence, they start up a mini Framework inside the existing Framework and perform all the bundle wiring as normal. This has great opportunities for being able to version whole apps and deploy them in a single OSGi engine without trampling on any other apps inside the same environment. It should be noted that not only is it a draft, but that it's also a proposed API and that not all the kinks are worked out, so it might not even make it into the final 4.2 release.

• Service Hooks BJ discussed Symmetric services and the Service Hook service, which will allow bundles to depend on other services but not worry about startup ordering. It feels like this has overlap with the Blueprint service, which will provide you an instance but (thread) block access to the service until it's wired up. Unfortunately, much of the presentation was about the basics with not much time devoted to the new aspect, so my terse analysis could be way off.

Experience with OSGi and Eclipse Many companies are talking not only about the services and developer products, but also their success with Equinox, OSGi and RCP for their internal applications. LinkedIn has been a heavy OSGi user and discussed it in the past; Yan Pujante came to EclipseCon and presented it for this audience. There were also real-world pain points and advantages, with the takeaway being that it's quite possible to implement but (as with any technology) there are learning curves. Michael Galpin of eBay discussed their internal use of Eclipse @ eBay, along with some of their internal plugins that they used to support their development processes and toolsets.

DVCS This year's EclipseCon has co-incided with distributed version control systems growing in popularity, and I posted yesterday an overview of what's going on. At the Git BoF last night, a lot of good discussion was had; Doug will be updating the bug(s) on the subject before next week, so there'll be more accurate (and officialish) news on the subject then. Whilst there won't be anything officially supported for a while, it's probable that EGit will move from its current house to Eclipse by the end of next month if the proposal goes ahead. One reason why Git seems to be the favourite at the moment (other than momentum with other open-source projects and e.g. git.apache.org) is that the JGit library is a pure-Java solution (and not a Java wrapper like the SVN implementation) with a permissive license, so we could logically expect an out-of-the-box experience with Git at some point in the future instead of having to download third-party tools as is the case with SVN at the moment. Oh, and also, many of the Git (and JGit) developers are using Macs for development, so that's a supported platform :-)

Day 2 has been a long and tiring day, and whilst it's good to catch up (and get out a few press releases) it means that I'm already behind the times. Expect my EclipseCon wrapup to be somewhat delayed ...

PS Eclipse con tie of the week now hosted at alblue.blogspot.com (top right of page) and up and running ...

EclipseCon Tie of the Week

As EclipseCon draws to a close, I'm wearing my final tie. In the spirit of sharing, and for those that weren't able to make it, here's what they looked like over the week:

Tuesday	Wednesday	Thursday
Golden Gate	Clarinet	8Bit

So, time to vote for which one was your personal favourite. Click on the poll at alblue.blogspot.com (the top right of this page if you're on this page already) to record your vote (or follow the EclipseCon feedback process send an email with +1, -1 or 0 to feedback@eclipsecon.org with the tie name :-). I'll announce the winner at the end of March.

Distributed version control at Eclipse?

There's an on-going discussion on distributed version control for Eclipse at bug 257706. The discussion (and title) are heavily GIT focussed, but it's evolved into a more generic discussion on DVCS requirements on the whole.

There's clearly a chicken-and-egg thing with tool support for DVCS and the availability of the DVCS, not to mention the load on the resource-constrained admins of the Eclipse foundation servers. But it's bringing the discussion to a group of interested people about the pros/cons of those features generically.

One thing that a DVCS would do is to assist in on-going development of code which tracks the latest versions of Eclipse but which might not be held up by the committers resource availability to review. It would also help in the development of new code (say, objectiveclipse) which could allow concurrent development of new features which are not yet approved but whilst still tracking underlying changes to the platform itself.

The other point (raised by Doug in the CDT community talk) is that actually, all the commercial companies who ship on top of the Eclipse platform almost certainly have their own (internal) forks of the Eclipse codebase. Using DVCS upstream would facilitate a one-way (or two-way) interaction between up-stream and down-stream consumers of the platform.

Having a DVCS is more a question of when, rather than if, but there are discussions suggesting that an existing version control system is deprecated to take the resource. Since CVS is old and crufty, it's quite likely that that will ultimately be deprecated in favour of SVN, which in turn will be likely deprecated in favour of a DVCS in the distant future.

There's a bunch of different DVCS implementations - Git and Hg for example - and there's clearly going to be preferences one way or the other. Git probably has the momentum in some of the free software implementations (not the least of which is because it's used by the Linux kernel) but the Eclipse plugins for each DVCS have their own quirks. However, there are SVN-to-git mappers, so using something like that might be worthwhile; in fact, Apache have recently released git.apache.org, a read-only Git clone of the Apache SVN repository's projects. It's probably the case that Git will win out in the DVCS implementation choice at Eclipse, but it's far from likely that this will happen in the near future (although perhaps a review of the board after sufficient interest and post the July release trains might happen). Add your comments/thoughts/votes to bug 257706!

Those attending EclipseCon 2009 should consider attending Git BoF tonight, Wednesday for a general discussion about Git and DVCS in Eclipse.

EclipseCon Day 1 in review

Most of the news this week is coming out via the #eclipsecon twitter search tag; and if you're using an application like TweetDeck you can see the updates to the search occurring as they happen. Tweets aren't as permanent as blog entries though, so here's a roundup of what's happening.

Keynote address "The Social Mind: Designing like Groups Matter", given by Jeff Atwood (of Coding Horror fame) and Clay Shirky (author of the upcoming Here Comes Everybody book), looked at the social aspects of websites like Slashdot, YouTube and Stack Overflow, along with what worked and didn't. This drove a number of features that Stack Overflow has, like voting, tagging and commenting (with editing reserved for more reputable users). There were four 'scary ideas' put forward for interaction with Stack Overflow:

• Lower the bar for participation with no registration required
  • Tragedy of the commons means that you may get higher signal-to-noise
  • Stupid comments on YouTube exceed 48,000 on a single video - no-one will read that much
  • Some nuggets of note - e.g. Optical effects of Special Relativity has 150 well thought out/formatted comments
  • Stack Overflow's 'stupid comment' filter trained on YouTube
  • Most updates to Wikipedia examples tail off with only a single update by a single user - c.f. Asphalt has a few frequent updaters and many single updaters
• Trusting (some of) your users
  • The more worthwhile someone believes a user to be, the better they may be able to police the actions of others
  • The only resource that scales with the number of users is the number of users, so have self-policing sites
• Life is the world's biggest MMORPG
• And you don't get to respawn..
• Bad stuff happens
• Revision history and reversion means that it can be quicker to revert damage than cause the damage in the first place

E4 As with previous years, there's a lot of E4 news here. The plan is to get a release out for the Eclipse 2010 release as Eclipse 4.0, although the Eclipse 3.x stream will continue in parallel. Whereas in previous years there were discussions like 'wouldn't it be cool if', we're now in a situation where there's working (albeit prototype) code demonstrating declarative UIs (in a variety of XAML type formats). There's definitely advantages of a declarative UI, not the least of which is that styling via CSS allows for a much more flexible theming (or 'skinnable') aspect. I'm pretty sure that no-one has used the term 'skinnable' for the last four or five years - when app writers focussed more on could you redefine the UI rather than the usability of that UI - but nevertheless, it does lower the barrier for amending/moving the UI itself. Think of it as HTML for applications.

Sun and GlassFish This week, Sun announced the GlassFish Tools Bundle for Eclipse, which is in fact a fresh Eclipse install with a bunch of bundles installed (although it is possible to install the adaptor into an existing Java EE Eclipse install). They were also late-comers to the Gold sponsor category for EclipseCon, although sources have suggested this was more to do with bureaucracy within Sun rather than a late decision to attend. GlassFish v3 Prelude, based on OSGi, was also demonstrated.

OSGi As with previous years, EclipseCon is co-sited with OSGi DevCon, and there's several talks on the topic. However, unlike previous years (where talks were more focussed on the basics of what OSGi is), this year the focus is more on detailed patterns and use cases. The word from Eclipse is definitely runtime technology and a lot of developers here seem to get it. In addition, the OSGi 4.2 public draft is now available for comments.

That's just an overview of the types of talk I attended, but as you can see from the associated Twitter comments, there's a lot going on. And one of the main reasons for attending EclipseCon (rather than just reading blog posts about it) is to catch up with those you've been interacting with over the last year, or if it's your first time, to put a face (or a tie) behind the name. I couldn't make it last year, but it's great to catch up with those that were here from previous years.

Stay tuned for further EclipseCon news ...

EclipseCon ties are back!

Following in the theme of the previous tie-of-the-week vote, I'm going through a different set of ties for this week's EclipseCon, with a vote tomorrow for the best tie. Yesterday's was the Golden Gate Bridge and today's is a clarinet - look out for me around the conference.

Updating Atom feed location for Eclipse posts

I'm just about to update the location for the Eclipse atom feed - this should be transparent to those clients that follow HTTP redirects automatically. However, if you see my collection of (old) Eclipse posts re-posted (i.e. those that ignore the atom:published field) then you might see duplicates being posted. If so, my apologies.