I recently had the opportunity to give a talk on the Eclipse Framework and how it hangs together. I’m also writing a book on the subject; and although O’Reilly originally expressed an idea in the book, it’s still awaiting a publisher to take the title. It will probably be released under the Creative Commons license in the future.
What is amusing about the Eclipse versus NetBeans debate is that most people still think of Eclipse as a Java Development Environment, and compare it to NetBeans on that footing. Well, Eclipse as a framework is much larger than Eclipse as a developer environment, although the latter is more well-known. Just reading posts on some of the Eclipse websites and plugin directories, you get the feeling that there is a large community working within the platform, not just the Java IDE.
I think this post sums up the point nicely: “Eclipse is not just an IDE that competes with NetBeans … Eclipse is a complete development platform that makes large parts of Java irrelevant.” Sun have never really quite ‘got’ Java as an application development language; although it is a very powerful programming language. Frameworks are what made Smalltalk popular; what makes coding in Mac OS X easy; and are the holy grail of reuse and patterns books around. Java just provides a low-level layer to provide simplistic access; for example, the URL class provides basic access, whilst Jakarta’s HttpClient provides a framework for building HTTP applications and HttpServlet provides basic web interaction, whilst Struts provides a framework for building web-based applications.
It’s probably better that Sun don’t control frameworks though, because there’s not a lot of evidence that up-front thought that happens. Consider the Date class, which returns years since 1900, or the fact that we’ve got basically two of the same interfaces in Iterator and Enumeration (and the ability to remove an object whilst traversing it is a bastardisation of the interface anyway; we could have equally had a sub-interface called ‘RemovableEnumeration’ that added that specific functionality if required). Or the fact that since 1.1, Java has a buggered threading model that processes the EventQueue resulting in all GUIs having to be killed with System.exit(). (Interesting note; they actually have apologetic documentation that describes this broken behaviour, and bug 4030718 that I was vehement about when 1.1 was broken; even to the extent that I wrote a patcher class that patched the classes.zip to show that this behaviour could be unbroken in time for the 1.2 release; in 1.4, they’ve finally marked it as closed.) By the way, another reason why SWT rocks is that they allow you to write your own threading for event handling; it’s why most standalone SWT apps have:
This allows the programmer to have fine-grain control over the thread, and whilst this is single-threaded, it doesn’t have to be. They even acknowledge this:
Note: The most common threading model for an SWT application is to run a single UI thread and perform long operations in computational threads. However, SWT does not restrict developers to this model. An application could run multiple UI-threads with a separate event loop in each thread.
In any case, the reason why people are excited about the Eclipse framework is that they are interested in what you can do with the platform, not just how good the IDE is. You only need to see the growing list of rich client applications to see that the momentum is gaining speed. And the best news of all is that the guidance of the platform and RCPs is a meritorium controlled by the open Eclipse organisation, so anyone can participate and guide the future; not just by JSRs.
www.rcpapps.org to provide a set of examples on how to write RCP applications, and how you can design and build applications that take advantage of all that the Eclipse frameworks have to offer.