Java web+database applications are usually filled to the brim with technologies. Many of these are hard to test and many of these may not add value. In order to explore TDD and Java applications, I practiced the Java EE Spike Kata in 2010. Here’s a video of me and Anders Karlsen doing this kata at JavaZone 2010.

A similar approach is likely useful for programmers using any technology. Therefore, I give you: The rules of the Architecture Spike Kata.

The problem

Create a web application that lets users register a Person with names and search for people. The Person objects should be saved in a data store that is similar to the technology you use daily (probably a relational database). The goal is to get a spike working as quickly as possible, so in the first iteration, the Person entity should probably only contain one field. You can add more fields and refactor the application later.

The rules

The most important rules are Robert Martin‘s three rules of Test-driven development:

• No code without test (that is, the code should never do something that isn’t required in order to get a test to pass)
• Only enough test to get to red (that is, the tests should run, give an error message and that error message should correct)
• Only enough code to get to green (that is, the tests should run and not give an error)
• (My addition: Refactor on green without adding functionality)

Secondly, application should be driven from the outside in. That is, your first test should be a top-level acceptance test that tests through http and html. It’s okay to comment out or @Ignore this test after it has run red for the first time.

Lastly, you should not introduce any technology before the pain of not doing so is blinding. The first time you do the kata in a language, don’t use a web framework beyond the language minimum (in Java, this means Servlets, in node.js it’s require('http'), in Ruby it means Rack). Don’t use a Object-Relational Mapping framework. Don’t use a dependency injection framework. Most definitely don’t use an application generator like Rails scaffold, Spring Roo or Lift. These frameworks can be real time savers, but this kata is about understanding how the underlying technology works.

As a second iteration, use the technologies you use on a daily basis, but this time set up from scratch. For example, if your project uses Hibernate, try configuring the session factory by hand. By using frameworks in simplest way possible, you’ll both learn more about what they bring to the table and how to use them properly. For complex technology like Hibernate, there’s no substitute for deeper understanding.

What to expect

So far, I’ve only done the Architecture Spike Kata in Java. But on the other hand, I’ve done it around 50 times together with more than ten other developers. I’ve written about how to get started with the Java EE Spike Kata (in Norwegian) on my blog before.

This is what I’ve learned about working with web applications in Java:

• Most Java web frameworks seem to harm more than they help
• Hibernate is a bitch to set up, but once it’s working, it saves a lot of hassle
• Using TDD with Hibernate helped me understand how to use Hibernate more effectively
• I’ve stopped using dependency injection frameworks (but kept on using dependency injection as a pattern)
• I have learned several ways to test web applications and database access independently and integrated
• I no longer have to expend mental energy to write tests for full stack application

The first time I write this kata with another developer, it takes around 3 to 5 hours, depending on the experience level of my pair. After running through it a few times, most developers can complete the task in less than an hour.

We get better through practice, and the Architecture Spike Kata is a way to practice TDD with the technologies that you use daily and get a better understanding of what’s going on.

The quick analysis

Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Customer: Sure. The next task on the backlog is to send the payment request to the accounting system

Developer: Yeah. Um… well, we’re not really ready for the integration tasks yet. I was thinking that we might perhaps pick another user interface task. Would that be okay?

Customer: No problem. Let’s see…. how about “road project submits funding request”?

Developer: Great. What’s that?

Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.

Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?

Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.

Developer: That should be doable.

They work out a few more details and get on their way. Total time, 30 minutes

The low ambition implementation

Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.

Customer: Great, let’s see it! Let’s see… There’s a new “apply for funding request” menu item. Nice. But it should be “Fund road project” (developer notes feedback). Let me try and press it… Hmm… “select municipality”? Why do I get that?

Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.

Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).

Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.

Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.

Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?

Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.

Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.

Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.

Developer: (sigh) I guess it can’t be helped. We’re on it.

Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.

The quick completion

Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.

Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.

Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!

The contrast

Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.

When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.

When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.

On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?

New language features

Java 7 has a few new language features. Sadly, the most exciting ones have been postponed until Java 8. The following 3 features may show up in your pretty quickly, though:

try ( BufferedReader reader = new BufferedReader(new FileReader(...))) {
  String line = reader.readLine();
  process(line);
}

This is the try-with-resources or Automatic Resource Management block. If you declare a variable in the try() statement, Java automatically calls close on it, like you would in a finally block. This is a small improvement, but nice. You can use try-with-resources on your own object by implementing the new interface java.lang.AutoCloseable.

try {
    clazz.getConstructor(List.class).newInstance(list);
} catch (InstantiationException|IllegalAccessException|InvocationTargetException|NoSuchMethodException e) {
    throw new RuntimeException("I really don't care", e);
}

This is the multi-catch statement. It’s useful because of the load of checked exceptions on the sanity of your average Java-developer. It’s nice, but hardly revolutionary. It makes me really wish we got rid of checked exceptions, though.

Map<> ordersPerCustomer = new HashMap<customer ,List<Order>>();
</customer>

This is type inference for Generic Instance Creation. Saves a few keystrokes without removing any type safety. Again, a nice, but very small improvement.

There are a few more language features, but I expect they will see very little use.

JVM changes

The Java virtual machine gets a new instruction: invokedynamic. Using invokedynamic, the JVM can invoke a method on an object without having to know on which class or interface the method is declared. If it walks like a duck and talks like a duck…

Invokedynamic will be very helpful for implementors of dynamic languages in the JVM, so it’s great. But the average developer will never encounter it in the wild.

Library changes

Looking at the release notes for Java 7, you may first suspect that there are some interesting library changes here. However, when examining the list more thoroughly, I couldn’t find a single change that I expect I will actually use. The library changes are mostly low-level, behind the scenes fixes of small problems.

Conclusions

So there it is: try-with-resources, multi-catch and a very limited type inference. Hopefully, Java 8 will be released as planned in late 2012 with all the stuff we’ve been waiting for. If so, I expect most shops will skip Java 7. But if Java 8 follows the pattern of delays from Java 7, these slim pickings may be all the crumbs the Java community gets for another five years.

As dependency injection frameworks like Spring have become central in software applications in the last few years, the conventional view is now that the Singleton pattern is evil and should never be used. Instead, relationships between objects in your system should be managed by a dependency injection container. I have started disliking the consequence of this strategy very much: All coupling in my system becomes implicit and harder to understand. I have instead reverted to using design patterns like the Singleton pattern, but with a slight twist.

The Singleton-initialized field

Here is an example of a Singleton-initialized field:

public class PersonService {
 
    private PersonDao personDao;
 
    public PersonService(PersonDao personDao) {
        this.personDao = personDao;
    }
 
    public PersonService() {
        SessionFactory sessionFactory = 
              MyHibernateContext.getSessionFactoryInstance();
        this.personDao = new HibernatePersonDao(sessionFactory);
    }
 
    public void someServiceMethod() {
       // Do something with personDao
    }
 
}

When I write a test for this class, the test code overrides the PersonDao by passing it to the non-default constructor.

@Test
public void shouldDoSomething() {
   PersonService service = new PersonService(mockPersonDao);
   service.someServiceMethod();
   verify(mockPersonDao).findAllPeople();
}

Compared: The dependency injection way

The now-conventional way of doing the same thing is with dependency injection:

public class PersonService {
 
    private PersonDao personDao;
 
    @Inject
    public PersonService(PersonDao personDao) {
        this.personDao = personDao;
    }
 
    public void someServiceMethod() {
       // Do something with personDao
    }
}

And the test will set up the dependencies using a container:

@RunWith(SpringTestRunner.class)
@Configuration("src/test/resources/test-context.xml")
public class PersonServiceTest {
 
   @Resource
   private PersonService service;
 
   @Resource
   private PersonDao mockPersonDao;
 
   @Test
   public void shouldDoSomething() {
      service.someServiceMethod();
      verify(mockPersonDao).findAllPeople();
   }
}

Somewhere in the realms of test-context.xml we will configure the fact that PersonDao should be provided by a mock:

public class MyDependencyConfigTest extends MyDependencyConfig {
    @Bean
    public PersonDao personService() {
        return new MockPersonDao();
    }
}

The problem: Declarative programming

With a dependency injection container, the components in my code are loosely coupled. Indeed, this is the main selling point of dependency injection. But sometimes, loosely coupled code is the problem.

First, understanding which dependency is actually used (and why!) can require a lot of brain power: It will require you to consider all possible configurations when you look at a dependency and it will not work well with the normal code navigation functionality of your IDE. Second, the configuration will tend to deteriorate: When you no longer use a dependency, will you check whether you can remove it, or will you just leave it there to be safe?

Lastly, it can be hard to spot errors in the configuration:

I once had a service that needed had a @Resource TransactionManager and a @Resource DataSource. However, the system had a pair of each. The test code was correct, but in the production code, I had by accident configured the wrong TransactionManager. The effect was that the Service didn’t run in a transaction for the correct data source. That is: It didn’t really run in a transaction. The problem with this is that you only discover the problem if you scrutinize the contents of the database after the transaction was supposed to be rolled back.

Dependency injection in specific and declarative programming in general mean More Magic. More Magic is seldom a good thing, at least not when there are simple, time-tested strategies that work. Even if said strategies have fallen out of fashion.

This dependency injection madness must end!

I often find myself in a situation where I have a method call that’s starting to accumulate parameters. Something like this:

showPersonCreateForm(writer, firstName, firstNameErrorMessage, lastName, lastNameErrorMessage,....);

After three or four parameters, the need to refactor is starting to become evident. I would rather have something like this:

CreatePersonForm form = new CreatePersonForm();
form.setFirstName(firstName);
form.setFirstNameErrorMessage(firstName);
form.setLastName(firstName);
form.setLastNameErrorMessage(firstName);
form.show(writer);

This is one of the more complex simple refactorings you can make, and it requires several steps. In this five minute video, I show how to perform such a refactoring without any steps that break my code:

The screencast was created using the free BB FlashBack Express on Windows. All the magic you see happening while I program is either ctrl-space (complete) or ctrl-1 (quick fix).

Can you modify your code without going thought long stages of nothing working? I think you can!

This is nothing new, but I’ve noticed that not many developers know how to use it, so I hope this video may be useful:

If you would rather not include a library like cglib in your code and you don’t mind having to create an interface to create this sort of code, you can do the same with java.lang.reflect.Proxy.

I got some comments on my last post about Eclipse stenography about the animated gifs. I know this can be annoying, but I considered the alternative: To have you mouse-over or click a picture to animate it. I’m afraid that the pictures will sort of disappear from your attention if I do this. So I’ll try again. But this time, I’ll put the images below the fold. Click on to see the ten tips.

1: Create a class that you refer to in existing code

2: If you create a class and Eclipse detects that it must implement an interface, Eclipse will generate stub implementations of the interface for you

3: As above: If you code references a non-existing constructor, Eclipse can create it for you

4: And if a parameter to a constructor or method is unused, Eclipse can create a new field and assign the parameter to it

5: When the cursor is on an expression, Eclipse can assign the expression to a local variable

6: If you’re comparing two values, and only one can be null, Eclipse can invert the objects to avoid the null

7: Eclipse can help you massage a conditional expression into shape

8: Convert old style loops to fancy new loops, where possible

9: Take care of those annoying checked exceptions

On a related note, there’s only one thing I really hate about the Java language: Checked exceptions. They get in the way of code coverage, they trick novice developers to deal with problems locally instead of at the top level, and ultimately, they introduce more bugs. And that’s a fact!

10: When you have a field that’s just not being used, why not have Eclipse help you violate encapsulation with less work

What’s your favorite?

Eclipse (and other IDEs) have a myriad of smart tricks. For Eclipse, ctrl-space and ctrl-1 give you access to a surprising amount of functionality. Do you know any other keyboard shortcut that’s as versatile? Or as useful? Do share! :-)

I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session. The result is the Java EE Spike Kata. My colleagues in Steria, Anders Karlsen and Ivar Nilsen have been great to work with. Between us, we’ve showed the kata at three conferences, and more are coming.

Here is the performance at JavaZone 2010 by Anders Karlsen and myself.

Make sure to watch the video in full screen mode as there will be LOTS of code.

Some things to watch for when you’re watching a (paired) code kata:

• How are we working together? How often are we changing who’s at the keyboard? What will the person who’s not at the keyboard be doing?
• How do we progress from one test to the next? When do we decide to modify an existing test and when do we decide to add a new one? How much of the test do we write before we start modifying the production code?
• How are we writing the production code? How often are we refactoring existing code?
• How are we using the IDE? What tricks do we use to take advantage of the code completion facilities? How often do we use the mouse and how often do we use the keyboard?

I also hope to be putting up the video of me and Ivar Nilsen at the TelecomCity conference in Sweden. As we’d both practiced even more for that performance, I think it’s even smoother than the JavaZone performance.

Enjoy!

(Kudos to Cisco Norway, formerly Tandberg, for excellent filming services at JavaZone. And thank you to Robert “Uncle Bob” Martin for turning me on to code katas in the first place)

Just as a stenographer learns to take down information really fast, a good programmer can learn to write code really fast by taking advantage of his or her tools. In this post I’ll show you my secret code stenography tricks.

The basic way completion works is: You write something and press ctrl-space. Eclipse will respond with a list of option. Use the arrow keys to select an option and press enter. Eclipse will replace what you typed with the option.

Name completion

The most well-known form of completion: Start writing the name of a class or method, press-ctrl space, and Eclipse will complete the typing for you.

Notice the blue squares around “expected” and “actual”. These are “fields”. Use tab to jump between them.

New to many is the fact that Eclipse support CamelCase syntax when completing names:

When I type “TPH”, Eclipse finds to classes with names that match (“TaggedProfileHelper” and “TaggedProfileHolder”) and offers them to me as a list. When I type “TPHe”, Eclipse finds only one class that matches (“TaggedProfileHelper”), and expands it automatically.

Pro tip: Remove classes you don’t use but that often make completion ambiguous by going to Window->Preferences and adding the classes to Java->Appearance->Type filter.

Expand code template

Another fairly basic one: Type the name of a template (from Window->Preferences, Java->Editor->Templates) and press ctrl-space to insert it.

Notice that Eclipse brings up the type list on the first ctrl-space. Press ctrl-space again to show Template completions.

Pro tip: Edit and remove editor templates to make your coding faster. You may also add template, but I seldom find this as useful.

Override method

Now, we’re getting into new territory for most of you: In the class body, type the name of a method in the super class and press ctrl-space:

Eclipse offers to override the method for you. Notice that CamelCase completion works here.

Generate getters and setters

Yet another little know super trick: In the class body of a class with a field “name”, type “getN” and press ctrl-space to generate a getter, or “setN” to generate a setter:

Notice that CamelCasing doesn’t work perfectly here; you can’t type “gNa” to create a getter for “name”.

(It’s possible to generate getters and setters for a large number of fields with “Source->Generate getters and setters”. But when I only add one new field, I find code completion to be a faster option)

As I’ve been working on code katas, I’ve found many ways to speed up my programming in my IDE of choice. I hope Eclipse stenography or code completion can help you write code faster as well.

Mockito – “the best Java library named after a summery drink”

Mocking is a hotly debated subject within testing camps. I think a lot of the arguments come against mocking (beyond overuse…) come down to the fact that the last generation of mocking libraries left a lot to be desired. A desire that has been fulfilled by Mockito.

I will leave the examples at a minimum, but here’s an example from code I actually use a lot. Mocking the servlet API:

HttpServletRequest req = mock(HttpServletRequest.class);
HttpServletResponse resp = mock(HttpServletResponse.class);
 
when(req.getMethod()).thenReturn("GET");
 
servletUnderTest.service(req, resp);
 
verify(resp).setContentType("text/html");

For those of you who’ve struggled with jMock or it’s ilk, you may notice the concise syntax used to specify behavior (“when(…).thenReturn()”) and the fact that you don’t have to set up expectations before exercising the code.

LambdaJ – “making Java beautiful and incomprehensible”

LambdaJ pretty much starts with the realizations that waiting for new language features like closures may prove to be a very long wait indeed. Furthermore, anonymous inner classes may technically be used to simulate closures, but they are so ugly that not even a mother could love them.

Let’s look at an example: Finding the name of every member of the Simpsons family who’s older than 8, in order of age.

In plain Java:

List[Person] tmp = new ArrayList[Person]();
for (Person p : theSimpsons) {
  if (p.getAge() > 8) tmp.add(p);
}
Collections.sort(tmp, new Comparator() {
  public int compare(Person a, Person b) {
     return a.getAge() - b.getAge();
  }
});
List[String] names = new ArrayList[String]();
for (Person p : tmp) {
  names.add(p.getName());
}
System.out.println(names);

More modern languages are way ahead of Java. Here’s Ruby:

puts theSimpsons.select { |p| p.age > 8 }.sort_by(&:age).
     collect { |p| p.name }

The rather simple request is simple to express. Yay!

Java 7 may make this better.

System.out.println(theSimpsons.select(#(Person p) {
  return p.getAge() > 8;
}).sort_by(#(Person p) {
  return p.getAge();
}).collect(#(Person p) {
  return p.getName();
});

All in all, not a bad contender. What about LambdaJ:

System.out.println(with(theSimpsons)
    .retain(having(on(Person.class).getAge(), gt(8)))
    .sort(on(Person.class).getAge())
    .extract(on(Person.class).getName()));

It’s not perfect, but it has one thing to recommend it: This works with standard, everyday Java, today! There’s no special compilation crap. No other language. Nothin. Just plain old Java.

(Thanks to Mario Fusco for improving the example with LamdbaJ 2.3 syntax)

What’s going on

Both LambdaJ and Mockito use a tricky sleight-of-hand: Generate a dynamic subclass which records its method invocations for later use. Creating such an API is in principle easy, although my implementation leave a lot! of details unimplemented.

So: We want invocations on the generated class to be template/mock objects to be saved:

@Test
public void shouldRecordInvocations() throws Exception {
    Person template = DynSubclassDemo.on(Person.class);
    assertNull(DynSubclassDemo.lastMethodCall());
    template.getAge();
    assertEquals("getAge",
        DynSubclassDemo.lastMethodCall().getName());
}

This magic is surprisingly easy to implement with CgLib:

@SuppressWarnings("unchecked")
public static Object on(Class templateClass) {
    return Enhancer.create(templateClass, new InvocationHandler() {
        @Override
        public Object invoke(Object o, Method m, Object[] a) {
            lastMethodCall = m;
            return null;
        }
    });
}

This creates a subclass of the template class (in this case: Person). But every method in Person is overridden by calling the invocation handler. Which simply saves what method was called.

This makes it possible to implement a prototype of LambdaJ’s collect method:

@Test
public void shouldCallRecordedMethodForEveryObject() {
    names = DynSubclassDemo.collect(theSimpsons, 
            DynSubclassDemo.on(Person.class).getName());
    assertEquals(names, asList("Lisa", "Homer", "Marge", ...));
}
 
public static[T ,U] List[U] collect(Iterable[T] c, U property) {
    ArrayList[U] result = new ArrayList[U]();
    for (T t : c) {
        // An insane amount of exception handling removed
        result.add((U) lastMethodCall.invoke(t));
    }
    return result;
}

This is a gross simplification. LambdaJ handles many aspects that my prototype simple ignores: Chained method calls, multithreading, method arguments, and multiple invocations on the same line.

The future of Java

Maybe the future of Java isn’t extending the language. Maybe the future of Java isn’t replacing the language with Scala. Maybe the future of Java is smart people discovering smarter ways of using what’s already there. My hat off to Mario Fusco, Szczepan Faber and everybody who’s contributed to LambdaJ or Mockito.

Come to my talk at JavaZone to learn more!