I've been doing Eclipse RCP development for the past 2 months as part of my day job (nope, Swing is not dead, it just so happens the customer is an Eclipse shop), and while we used Eclipse 3.x initially we switched to Eclipse 4.x in recent weeks. Now, everyone following Eclipse knows that in the last 3 years there's been a big change when migrating from Eclipse 3.x to Eclipse 4.x, mainly due to a full overhaul in the platform's design. As someone staying in the periphery of the Eclipse community I couldn't help but to notice some similarities between Eclipse 4.x and Griffon.
Serendipity stroke during Øredev as I met with Lars Vogel (@vogella) during one of the breaks. We chatted for a while about our respective frameworks just to discover how similar in spirit and features they are. The following is a list of such features, and I'm just scratching the surface.
1. Dependency Injection
Eclipse4: Provides DI facilities implementing the standard javax.inject annotations plus a pair of extensions (@Optional and @Preference). I cannot stress enough how lightweight this mechanism is, and how easy is to get going with DI. Eclipse 4 follows a well defined pattern to find out the container of a particular instance when injection must take place. Lars has written an excellent tutorial on how to get started with Eclipse RCP applications under the new design; the dependency injection chapter contains a detailed description on this feature.
Griffon: All MVC members are automatically injected by name; this is how model and controller get injected into a View script. Also, service instances defined as properties on controllers follow the same rules. However, there are standard extensions that provide DI and more: spring, weld and guice. There's also the recent addition of a resource injection API that greatly simplifies setting up i18n aware resources.
2. Events
Eclipse4: Dealing with events requires two parts: a component that can trigger events, the other is a set of event handlers. The first part is provided by IEventBroker, a platform instantiated broker that can trigger events asynchronously (post) and synchronously (send). Here's some sample code showcasing this part:
Handling events requires the usage of special annotations on method arguments, either @EventTopic or @UIEventTopic, the latter makes sure the event handler is invoked inside the UI thread. So, this is how a component can handle the previously defined events
Once more, Lars made sure to publish a great tutorial on event handling.
Griffon: like in Eclipse, there are two parts involved with event publishing and handling: The EventRouter and event handlers. However Griffon's event mechanism differs a bit from Eclipse's. To begin with EventRouter may publish events in 3 modes
- synchronously
- asynchronously
- hybrid
The last one sends the event (sync) if the current thread is not the UI thread, otherwise it issues a post (async). The application instance is normally used as the event publisher, like so
In Eclipse, all event handlers are automatically discovered during boot time (here's why understanding E4's DI is so important). In Griffon however you must specify which instances may become event handlers. But, to simplify things all controller and service instances are automatically registered as event handlers. Here's how another controller may react to the previously defined events
Handlers must follow a naming convention, they can either be Closure properties (as the first case) or methods (as the second case). Developers may event define these event handlers in the following way
Griffon goes further by allowing any component to become a local event bus, just by annotating it with @EventPublisher
3. Multiple UI Toolkit Support
Eclipse4: Though SWT is the default UI toolkit of choice when writing Eclipse RCP application it's not the only option, as Kai Tödter has demonstrated in this entry at his blog. SWT, Swing and JavaFX; all work with Eclipse4 thanks to it's renderer framework. There's even a Vaadin port!
Griffon: Swing is the default UI toolkit of choice for Griffon as there are no additional JARs required other than the standard JDK to get started. But of course, being a framework that embraces choices it also provides support for SWT, JavaFX, Pivot and Qt. There's no equivalent for web based rendering, then again that's what Grails is for in the first case (and much more!).
4. UI Thread Management
Eclipse4: Given the different renderers supported by the platform there's an inherent need to provide a base abstraction on top that deals with the UI thread, as every toolkit makes its own assumptions and provides its own rules. Eclipse provides UISynchronizer to deal with this.
Griffon: Likewise, Griffon provides it's own UI thread abstraction in terms of UIThreadManager.
Conclusions
I'll continue my research on Eclipse 4 during the following weeks, the initial findings make me think there's a high chance that integration between both platforms is possible, whether that means a Griffon powered Eclipse RCP application or a Griffon application driven by an Eclipse4 kernel remains to be seen.
Keep on Groovying!
