March 27, 2011

Eclipsecon 2011

I really enjoy going to Eclipsecon even though for us Europeans the trip over takes forever and you have to fight jet lag due to the huge time difference.

This year I found many talks interesting and especially a couple of them touched on the same subject, namely how to design large-scale applications.

The talk Stop the Architecture Erosion of Eclipse And Open Source Projects explained the usual scenario: when a small application grows the architecture starts decaying, leading up to a non-maintainable mess of spaghetti code. As an example the project Findbugs was analyzed from the start, and with each version it was shown that new tangles (circular dependencies) had been introduced and was never fixed. There are several programs (both commercial and open-source) that can reveal these problems and even suggest improvements.




CDO3D

A really cool way of visualizing the run-time behavior of a program was shown in the CDO3D talk. CDO has a really good architecture that can handle large distributed EMF models. The object dependencies were visualized in 3D so that you could see when the client objects were committed to the server and how a second client was notified and populated with the new objects.

One of the most important goals in having a sound architecture is to avoiding tight coupling. In the talk Introduction to OSGi, Peter Kriens explained how OSGi added modules (bundles) to Java so that internal packages can be hidden. He explained the well proven pattern of communicating through interfaces so that you avoid a direct coupling between a consumer and its provider.
Avoiding direct coupling by communicating through an interface
The below diagram from his presentation summarizes nicely the four different patterns of communicating between a consumer and a provider. Peter Kriens explained that OSGi services, or (micro)Services as he likes to call them, can handle all four cases.

Patterns communicating between consumer and provider
OSGi has been getting a lot of critique for being complicated. With the introduction of declarative services and the tool support in Eclipse 3.x, it is now much easier to utilize dynamic services than trying to implement a ServiceTracker correctly. With Eclipse 4.x, dependency injection is a key theme in the architecture and OSGi services can easily be injected in parts (views or editors).

Sven Efftinge's talk on Dependency Injection reiterated the importance of not having static dependencies to enable unit testing with "test doubles" (stub-, mock-, fake- or dummy objects). He shared his experience on using the Google Guice (pronounced "Juice") dependency injection framework in the Xtext project. I also found out that there is a nice extension to Guice called Peaberry that integrates Guice nicely within an OSGi application developed with Eclipse. With the help of Peaberry you can inject OSGi services in your classes. It also provides an integration with the Eclipse extension framework so that views, commands, etc. can utilize Guice injections. During late hours I played around with Guice and Peaberry and it was actually very simple to get it working.

Another really cool technology from Google is GWT. In the GWT App start to finish, I learned how easy it is to write browser-based rich internet applications without hacking Javascript. Being able to use EMF in GWT as shown by Ed Merks, makes it even more compelling since you can store the state on the client in an EMF generated model implementation.

This was just a few of the highlights this year and with lots of inspiration and new energy I am now back home again quickly adjusting to summertime.