Writing games using GWT and Eclipse

Finally Angry Birds is available on the web platform! I was not so impressed by the news from Google I/O until I heard that the implementation was done using Google Web Toolkit (GWT), a technology that has caught my interest lately. The good thing with GWT is that I don't need to hack Javascript and HTML5, but rather continue using Java with my favorite editor/debugger: Eclipse.

The Google I/O session Kick-Ass Game Programming with Google Web Toolkit explains further that Angry Birds is using the Box2D physics engine, which according to the presenter's guess 90% of all iPhone games are using. The Google guys took the Java version of Box2D, ported it and optimized it for GWT (in 30 mins!), and wrote a cross-platform game abstraction library, called ForPlay.

The idea is really compelling; instead of writing and maintaining several codebases of your game for different platforms, a ForPlay game can be run on the web platform (HTML5), as a Java program or even using Flash. Thrilled to try out this new platform, I wrote my first "game", well ... not really a game, but I thought it would be interesting to see how our company logo behaves in free fall. The result is on http://findoutlogo.appspot.com. It is based on the "Hello Game" demo you get when checking out the ForPlay source.

The FindOut Logo game (hint: click to drop a new logo or click and drag to "throw it")

I am very glad to see that you can leverage the existing ecosystem of components, even when doing game programming, and that GWT seems to be a great technology for managing code sharing when dealing with many target platforms.

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.

Use Eclipse fragment plug-ins for your unit tests

Photo by b0jangles

When writing unit tests you need to be able to test all classes, including classes within internal packages (white-box testing). Of course the test classes can be placed in the same plug-in, but typically you don't want to have the test classes deployed with a release.

A fragment plug-in is typically used for platform specific content or localized resource files, but it turns out that they are very useful for testing purposes. The fragment adds all its classes to its host plug-in so that they are visible by the host classloader at run-time. You can not add dependencies directly to fragment plug-ins, but if you need to export packages from fragments it is possible. In order to see the contributed packages during development you should add the "Eclipse-ExtensibleAPI: true" to the host's MANIFEST.MF file.

Fragment plug-ins can also define and use extension points. This makes it possible to contribute tests from the fragment to a suite of tests by using an extension point.

More information on fragments and other OSGi topics can be found in the excellent book: OSGi and Equinox: Creating Highly Modular Java™ Systems

Visualizing Eclipse Project Dependencies with Zest

I wonder how many Java developers that are using Eclipse to develop systems the old-fashioned way without using OSGi? It feels awkward and strange not to use OSGi if you are used doing that, but sometimes you don't have a choice when working with legacy systems.


It is well known that when the system grows it gets harder to maintain a clear separation between different parts of the system. Dividing the system into Eclipse projects does not help much since the tool lacks functionality for managing project dependencies. When developing applications using plug-ins and OSGi I have used the PDE Dependency Visualization tool. However, it only works for plug-in projects and does not show project dependencies for standard Java projects.

Googling for an existing solution didn't help much. The only discussion about this was a suggestion to parse all .classpath files and build a DOT file for GraphViz to display. Oh well, I did some hacking for a while, forgetting everything I read in the Clean Code book. The result was a standalone Java program that generated the needed DOT file. It was working ok and the GraphViz tooling could create the graph as an image for me. What I really wanted, though, was to have a view in Eclipse that showed my dependencies just as the PDE Dependency tool does.

The PDE Dependency tool is using Zest: The Eclipse Visualization Toolkit, so I decided to take a look at it. To my surprise it turned out to have exactly what I needed, namely Zest Viewers modeled after JFace.

With that I could create what I needed with just these few steps:

1. Install the Graphical Editing Framework Zest Visualization Toolkit SDK in Eclipse.

2. Create a Plug-In Project using the "Plug-in with a view" template. Change the default names to be more suited, for example the view class name to "ProjectDependencies".

3. Add the following plug-in dependencies:

• org.eclipse.zest.core
• org.eclipse.zest.layouts
• org.eclipse.core.resources

4. In the view class, ProjectDependencies.java, change the TableViewer to a GraphViewer and use the following code in createPartControl :

public void createPartControl(Composite parent) {
  viewer = new GraphViewer(parent, SWT.NONE);
  viewer.setContentProvider(new ViewContentProvider());
  viewer.setLabelProvider(new ViewLabelProvider());
  viewer.setLayoutAlgorithm(new TreeLayoutAlgorithm(LayoutStyles.NO_LAYOUT_NODE_RESIZING));
  viewer.setConnectionStyle(ZestStyles.CONNECTIONS_DIRECTED | ZestStyles.CONNECTIONS_DASH);
  viewer.setInput(null);

5. Change the content provider to implement the IGraphEntityContentProvider interface. Since the Resources plug-in already has the model of all Eclipse projects and its dependencies I can easily use it to return what is needed for implementing the content provider:

class ViewContentProvider implements IGraphEntityContentProvider {
  public Object[] getElements(Object parent) {
    // Return all projects in the workspace
    return ResourcesPlugin.getWorkspace().getRoot().getProjects();
  }

  public Object[] getConnectedTo(Object entity) {
    IProject project = (IProject) entity;
    try {
      // Return the project dependencies
      return project.getReferencedProjects();
    } catch (CoreException e) { }
    return null;
  }

  public void dispose() { }
  public void inputChanged(Viewer viewer, Object oldInput, Object newInput) { }
}

6.The last step is to change the ViewLabelProvider to return the project name.

class ViewLabelProvider extends LabelProvider {
  public String getText(Object element) {
    if (!(element instanceof IProject))
      return null;

    IProject project = (IProject) element;
    return project.getName();
  }

  public Image getImage(Object obj) {
    return null;
  }
}

Running the plug-in project as an Eclipse application and showing the view shows the project dependency graph:

Zest contains a lot more that could be utilized, such as a number of different layout algorithms, but this simple solution was exactly what I needed. I was surprised to see how easily I could achieve it, once I found the right component to reuse. Reusing existing software feels great, and the Eclipse platform has a lot of it!