Playing with Spring's RestTemplate

A couple of week ago, I saw a talk on Spring 3.0's MVC REST support. It's quite impressive how simple SpringSource made REST development by applying the proven concepts of the core Spring Framework.

One of those great core concepts is Templates. Spring's Data Access Framework is an example, where templates are used extensively. One of the templates is the JDBCTemplate. It provides a set of predefined methods to access a database, without worrying about Connection management or Exception handling. Templates are a nice way to help you the the job done, without constraining flexibility. The book "Building Spring 2 Enterprise Applications", which I reviewed last year, there's a whole chapter on Data Access and the corresponding Templates.

The RestTemplate is the latest child in the family. Arjen Poutsma from SpringSource wrote a blog entry about it and describes it as follows:

The RestTemplate is the central Spring class for client-side HTTP access. Conceptually, it is very similar to the JdbcTemplate, JmsTemplate, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that the RestTemplate is thread-safe once constructed, and that you can use callbacks to customize its operations.

In the before mentioned blog post, Arjen shows how to pull pictures from Flickr, using their REST API, and display them in a JFrame. He uses an XML based approach, whereas I'll show you some code, which handles JSON:



You can see it's quite easy to work with a RestTemplate. You simply create an instance, tell that instance what your expected content is going to be and you are good to go. In this case we expect the request and response to be JSON. Spring is using the Jackson JSON Processor, to automagically map POJOs to JSON and all the way back.

The concept of a MessageConverter is really neat. You can set multiple converters and specify to use a certain converter for certain POJOs. You can also handle multiple content types by setting multiple instances of MessageConverter.

In order to make a REST call with the predefined MessageConverter, you simply use the getForObject method. You pass the url to call, the type the response is supposed to be mapped to and the values to be replaced in the url. The type of the response is actually a wrapper class:



It is necessary since the following JSON response, which is represented in the POJO Issue, needs some kind of holder object:



As you can see, it's really easy to work with Spring's new RestTemplate. These couple of lines are enough to retrieve a JSON or XML response from a REST call. With the Template approach, you have the full flexibility to hook almost every method and tweak it to your needs.

Finally Running with the Snow Leopard

A little note upfront - this is not about software development, so if you are solely here to read about my take on coding, this blog entry is not for you!

A little more than 2 months ago I pre-ordered Apple's new Mac OS X 10.6 aka Snow Leopard one week before the official release at Gravis. As it turns out, it was a bad idea, because it took Gravis more than 6 weeks to deliver, but I digress...

After finally receiving my Family Pack, I installed the Snow Leopard on my wife's brand new MacBook. The upgrade was smooth and finished after only about 40 minutes. However, when it came to my old MacBook Pro, the tragedy began...

The first attempt to install Snow Leopard resulted in the installer quitting and rebooting the old Mac OS X as if nothing happened. Booting from the 10.6 DVD and then running the installer didn't help as well. I tried a couple of times, but the Snow Leopard wouldn't come out of the cage. Instead, I got an error message like "An error occurred while installing Mac OS X".

My second attempt was borrowing a colleagues copy of Snow Leopard and trying to install it using my built-in DVD. You might have guessed it - it failed as well, with the same error message. The next attempt was getting an external drive, which I hooked up using FireWire. Unfortunately, neither my nor my colleagues Snow Leopard DVD would let me install.

After I spent hours of trying to tame this animal, I decided to leverage my wife's MacBook as a remote dvd drive. It's pretty easy to setup and worked like a charm, however it didn't get my anywhere installing the new Mac OS X. The same problem here: the installer hangs after a while no matter which DVD I tried.

My last resort was using a USB stick/drive for installation. I found a nice description (german) on the web, which included the following steps:

1. create an image of Snow Leopard using Disk Utility (I used my wife's MacBook for that)
2. restore that image to your USB stick (I got an 8GB stick)
3. boot from your USB stick (hold option/alt while booting and select the USB drive)
4. run the installer

My stick didn't work out of the box, I had to reformat it - since it came FAT32 formatted and I had to run "Scan Image for Restore", which you can find under the Image menu in Disk Utility. After getting my USB drive ready and following the steps above, it worked like a charm. The installation took about an hour and went smoothly, without any problems.

Although I had so much trouble getting Snow Leopard installed, it was worth the pain! My system feels much more snappy and responsive now. Snow Leopard needs less space on my quite limited hard drive and Time Machine backups are reasonably fast now.

Overall, I'm quite happy jumping though all those hoops to the new Mac OS X Snow Leopard, although the experience wasn't very Apple-like.

Dependency Injection Obscures Your Code

During listening to Software Engineering Radio's Episode 148 - "Software Archaeology with Dave Thomas", I got quite annoyed by a comment made by one of the respected authors of "The Pragmatic Programmer".

To quote Dave Thomas correctly, here's what he said at around 23 minutes into the podcast:

... that is one of the reasons why I, in general, are not very happy with the DI style of development, because I actually think it obscures the code quite a lot, when it comes to reading it ..... what it actually does is, it give you another dimension, that you have to read in order to understand the code.

My first reaction was "What the deuce!?!". I mean how can someone claim, that Dependency Injection obscures code and makes reading code harder? Are all those hours I spent blogging and promoting DI in vain? Are the SpringSource guys wrong or is Dave Thomas just crazy?

However, his statement and even his argument are completely reasonable, if you listen to the first couple of minutes of the podcast. Dave said at around 11 minutes into the podcast:

.... actually, I don't typically use an IDE, I use an editor like Textmate on the Mac.

And there you go! No wonder, you'll find it harder to read and understand code, if you compare the following two screenshots from a bunch of code, using Spring:





If you are reading the code above and don't understand where those two dependencies in the constructor come from, your IDE gives you a hint, without leaving the context of that particular file. You know that, they'll be injected by Spring. In addition to that, you can even directly navigate to the configuration file with a single click.

Now if you are using a text editor, you really have no idea where to look for. I guess you would have to grep for new TxTestService(). In case of using Spring, not even that would give you any more clues.

Don't get me wrong, if Dave likes Textmate better than an IDE - fair enough! I just think everyone should use the right tool for the right job! Frankly, an IDE makes a much better job here than a plain text editor.

I think the Java world has amazing tooling and in my opinion there's almost the philosophy, that if there is no tool support for a technology - it sucks. I don't fully agree with that. However, I do think that, when it comes to Java, tool support can definitely
assist you reading and thus understanding code.

RESTful applications in practise @ JUG-Ka

This coming Wednesday Gregor Roth from 1&1, you might know him from his InfoQ article, is going to give a talk on RESTful applications at the Java User Group Karlsruhe.

He will show how to implement applications leveraging a RESTful architecture and point out the mismatch between a RESTful and RPC-style approach. Furthermore Gregor will highlight the difference between HTTP PUT and POST and finally demonstrate how to implement none CRUD operations using REST.

I'm really looking forward to this talk. In my spare time I developed the REST interface for an Android game and it's going to be interesting to see what we could have done better and hopefully what we've got right.

As usual, the talk will be held at University Karlsruhe in room 102, which is located in the basement. We'll start at 7:15pm, if the door opens as planned this time.

JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in our monthly lottery, send me an email. The winners will be announced at the end of the talk. In addition to that, Atlassian sponsored a couple of great T-Shirts, which you can pick up at the end of the talk.

If you want to know more about upcoming talks, subscribe to our Google Calendar. You'll also be able to see the planned talks for 2010.

Having Fun with JDK's tools.jar

This week I had to trace a bug in a legacy application, I'm maintaining at the moment, which drove me up the wall. The application uses a class from JDK's tools.jar, to determine the JVM instances currently running. Unfortunately, there are incompatibilities between JDK versions.

Tracking down the bug took a humongous amount of time, because the fun part of working on a legacy application is that all the developers, which are responsible for the code you are maintaining, are usually no longer available. Don't even get me started on documentation! However, as a good developer, I created the following JUnit test, to isolate the problem from the rest of the code.


If you run this test with Sun's JRE 1.6 and tools.jar of Sun's JDK 1.6 on the classpath, you won't encounter an problems. However, with my current project, we need backward compatibility with other Java versions. That means, there are multiple tools.jar on the classpath, in different versions. Depending on their order, the test above fails or succeeds.

More precisely, there is a JDK 1.4 and 1.5 version of tools.jar on the classpath, in addition to the 1.6 version. 1.6 is needed, because in previous JDKs the class VirtualMachine doesn't reside in the package com.sun.tools.attach. So running the test without tools.jar in version 1.6, you'll get a NoClassDefFoundError.

So what's the problem you might ask? As long as tools.jar of JDK 1.6 is on the classpath, when running the aforementioned test, everything should be okay, right? It should be, but it isn't. As soon as tools.jar of JDK 1.5 is before the 1.6 version on the runtime classpath, the test fails. Every other combination works just fine.

Why tools.jar of JDK 1.5 causes this problem is a mystery to me. Sun's bug parade, doesn't contain any relevant information - at least I couldn't find any. Frankly, I think this problem is so absurd, that I cannot motivate myself getting to the bottom of it.

Nevertheless, the problem exists in our application and we'll have to find a solution. I guess that's the reason why it's a legacy application - I have to deal with problems that are totally outdated and nobody knows the answer to.