Author: David

Joe Darcy and Maurizio Cimadamore gave a preview of the changes coming up in Project Coin. These are small changes to the Java language that will be added to Java 7. They all look pretty useful and include:

• Strings in switch
• Collection literals
• <> (generic type inference)
• Multicatch

catch (ClassNotFoundException | NoSuchMethodException e) {
    // Do something
    throw(e);
}

Bill Pugh’s session was as popular as expected for his talk about defective code and how static analysis with FindBugs can help. I’ve heard Bill talk about this stuff before but this time he was emphasising that not all bugs are equal. All code has bugs but some mistakes don’t really matter.

Google’s code has over 1000 null pointer bugs but few if any NullPointerExceptions in running code are caused by these. You need to determine which bugs are worth your time to fix.

The most important bugs are generally those which can cost you money on the first day they manifest themselves and those bugs that occur silently. This is why Bill is a fan of runtime exceptions; if something unexpected happens, you want to know about it.

Devoxx is held in a massive cinema complex and so after all the talks today the organisers put on a showing of The Social Network, a movie about the founders of Facebook. I really enjoyed the film. All the performances were great and I really liked the soundtrack by Trent Reznor. You don’t need to be a geek to enjoy this film. I don’t know how much of it is actually true but it paints an interesting picture of Mark Zuckerberg and draws nice connections between our concepts of ‘friendship’.

This talk by Costin Leau was about the new caching features in Spring 3.1.

After going over some problems you can face when caching (stale data, thrashing, distributed caches) and different caching patterns he introduced the declarative caching of Spring 3.1.

It uses AOP and can be declared on methods by adding the @Cacheable annotation. This annotation caches a method’s return value using it’s parameters as the key although this can be customised.

Eg:

@Cacheable
public Owner loadOwner(int id);

@Cacheable("owners")
public Owner loadOwner(int id);

// Using Spring expression language
@Cacheable(key="tag.name")
public Owner loadOwner(Tag tag, Date created);

@Cacheable(key="T(someType).hash(name)")
public Owner loadOwner(String name);

// Only cache on condition
@Cacheable(condition="name < 10")
public Owner loadOwner(String name, Date created);

The @CacheEvict annotation invalidates the cache:

@CacheEvict
public void deleteOwner(int id);

@CacheEvict("owners", key="id")
public void deleteOwner(int id, boolean saveCopy);

@CacheEvict(name="owners", allEntries=true)
public void batchUpdate()

You can also use your own stereotype annotations. Instead of spreading @Cacheable everywhere:

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@Cacheable("results")
public @interface SlowService {

}

@SlowService
public Source search(String tag) {...}

Spring is not a cache provider itself. You plug in your own cache provider (ehcache, JBoss Cache, etc).

I doubt Joshua Bloch suffers from performance anxiety but it was slightly ironic that there were some technical problems before he started his talk, titled Performance Anxiety, to an absolutely packed room at Devoxx today. I knew it would be a popular session so I got there early and so managed to find a seat, unlike the others who sat on the steps or crowded the doorway.

His talk was about microbenchmarking – measuring the performance of a small piece of code as opposed to profiling an application.

In the good old days performance could be estimated simply by counting program instructions. Now it is simply impossible to do this because of the ‘abstraction gap’. As code has become more and more complex it has become harder and harder to estimate and measure the performance. Complexity and predictability are inversely related.

Even benchmarking code doesn’t really work with consecutive runs often showing a variance of 20%. The code and systems are so complex nobody really knows where this variance comes from.

The solution is to run a bunch of JVMs in sequence and then statistically analyse the data (mean, median, standard dev, etc).

Basically, benchmarking is really, really hard and most benchmarks are seriously broken. Either the results are unrelated to the test or the error bars exceed the measured values.

Caliper is microbenchmarking framework from Google which can help.