Java on Appengine with Spring: not a walk in the park

Over the past few weeks I’ve been experimenting with Google Appengine. Its benefits are well documented, but when you actually dive into development there’s a few things that are troublesome for those developers that are used to deploying Spring based applications on say, Apache Tomcat. This posting is not an appengine-bashing, it just mentions a few things that I think developers should be aware of.To me, most of the problems have arisen with the persistence layer provided by Appengine. I understand the concept of Entity groups and its limits, although it would be helpful if Google would point out in its documentation that an owned relationship is the same as a composite or value type, which seem to me to be more common terms.

So sure it is possible to work around the particularities, or even to benefit from them but it is important for developers to be aware of them.

To JDO or to JPA?

Google is not being very clear about why appear to be promoting the use of JDO. This may be particular to me, but I haven’t really come across JDO a lot in projects. Many developers are familiar with JPA and Google is aware of that. So, JPA is supported by Appengine but most of the documentation is about JDO. That gave me the impression that the Appengine team, for some reason, prefers that you use JDO. That is, until I read this comment by Appengine team member Max Ross, in a comment on one of his excellent blogposts:

If you’re not already familiar with JDO or JPA, use JDO because our documentation is better. If you’re more familiar with JDO than JPA, use JDO. If you’re more familiar with JPA than JDO, use JPA. If you’re equally familiar with both then you probably have a preference, so use the one you prefer.

This begs the question: why is the JDO documentation better than the documentation for JPA? In my mind, JPA is way more popular than JDO so I don’t quite understand why the Appengine team would focus on providing documentation for JDO. Do they believe JDO is a better fit for the particularities of the Datastore? If that is the case then they should voice that in their documentation, ending the confusion for so many developers.

Using Spring

There is no arguing that Spring Framework today is the de-facto standard for building Java web applications, and in this posting I will not go into why, in most cases, it is a valuable addition to your toolset.  When it comes to wiring up everything from the business layer and downwards, the debate about Spring’s value is over.

If you are an experienced user of Spring Framework you may find yourself wandering around the blogosphere for quite a while, reading contradictory posts about, for example, how to configure your JPA EntityManagerFactory. For me, this blog by ‘objectuser’ has proven to an excellent source of information when you’re struggling with JPA and Spring Still, bloggers are having a hard time (do read the comment by ‘Sud’) finding the solution for things like using the PersistenceAnnotationBeanPostProcessor, which Spring does implicitly when you use JPA. This is complicated further by the relatively recent release of Spring 3.0 and rapid releases of new versions of the Appengine SDK, so you may feel like you’re shooting on a moving target. I suppose that’s the price of being on the cutting edge, so you are warned :)


If you are a Maven user, there is a plugin available that should make life easier. Google is not doing anything about it, so it’s a community effort, which is fine. Using it was a bit problematic, as the guys developing it where releasing new version in rapid succession, each claiming that a specific bug was fixed while it wasn’t. It seems to me that the quality is beta but it still is the best thing out there.


Leave a Reply