Haul: Hunting Game

7. March, 2010

Scene 1.8 “Hunting Game” is ready for you:

1.8 Hunting Game – On the surface of the jungle world, Forne tries very hard not to be captured by the Haul rescue team.

Table of contents

Previous post: Haul: Enemy Mine


1.8 Jagdspiel – Auf der Oberfläche des Dschungel Planeten versucht Forne alles, um nicht dem Rettungsteam der Haul in die Pfoten zu fallen.

Inhaltsverzeichnis


Spring Roo

5. March, 2010

[Update November, 5th] I tried Roo 1.1. See this blog post.

[Update March, 17th] After posting this, the guys from Roo posted the comments below. The command line parser bug is fixed, the dependencies will be fixed in the next version and they are investigating a fix I sent them for the NoClassDefFoundError. Not everything is perfect but at least they work on it 🙂

I just tried the ten minute example of Spring Roo. It took a lot more than ten minutes to get a huge exception. Oh well. Some notes:

Roo expects a vanilla Maven installation. If you’re behind a proxy like Nexus which limits what Maven can download, you loose. The Roo guys have copied everything (like log4j) in their own Maven repository under a weird name (org.apache.log4j:com.springsource.org.apache.log4j:1.2.15). So after working with Roo, you have a tainted repository with a lot of duplicate entries. Well done.

Of course, not everything has been copied. So some stuff comes from central, some from springsource. This meant half an hour setup of our Nexus server, trying to avoid to break it for the rest of the team.

When I try to run the app, I get

Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.validation.beanvalidation.LocalValidatorFactoryBean#0':
Invocation of init method failed; nested exception is
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

I see. Well, your 10 minutes is up. Oh, and there is a bug: controller all works while controller all doesn’t. The difference? There is more than one space after the command. This breaks the parser (and the TAB completion). I’d file a bug if I knew how. A prominent link on the web site (that doesn’t lead to the general SpringSource Enterprise Support) would be nice.


Java Tricks: Lazy initialization

4. March, 2010

If you’re a Java developer and you’re concerned about performance, you’ve probably encountered the (broken) double checked locking pattern (which I won’t reproduce here to make sure no one copies it accidentally. If you care, read the Wikipedia article).

Joshua Block has proposed a solution but there are a couple of fine points to it. If you don’t get it right, things are going to break in odd ways. So this should go into a helper class which handles all the boiler plate code. A post about final variables pointed me in the right direction. So without further ado, the LazyInit class:

/** Lazy initialization of a field value based on the (correct)
 * double checked locking idiom by Joschua Bloch
 * 
 * <p>See "Effective Java, Second Edition", p. 283
 */
public abstract class LazyInit<T>
{
    private volatile T field;
    
    /** Return the value.
     * 
     *  <p>If the value is still <code>null</code>, the method will block and
     *  invoke <code>computeValue()</code>. Calls from other threads will wait
     *  until the call from the first thread will complete.
     */
    public T get ()
    {
        T result = field;
        if (result == null) // First check (no locking)
        {
            synchronized (this)
            {
                result = field;
                if (result == null) // Second check (with locking)
                {
                    field = result = computeValue ();
                }
            }
        }
        return result;
    }

    protected abstract T computeValue ();
    
    /** Setter for tests */
    public synchronized void set (T value)
    {
        field = value;
    }
}

As an additional goodie, it allows you to override the value in tests. Here is how to use this code:

    private LazyInit<String> field1 = new LazyInit<String> () {
        
        @Override
        protected String computeValue ()
        {
            return "value";
        }
    };

    @Test
    public void testLazyInit () throws Exception
    {
        assertEquals ("value", field1.get ());
    }

Simple, isn’t it?


Better bug reporting

3. March, 2010

In his blog, stephan writes about the problems you can have as a bug reporter. Basically, when you encounter a bug, you’re in the middle of something that you need to get done. You don’t have time to analyze the bug, collect all the information that might be around, note it down and write a good bug report.

Instead you need to get your job done. Then, later (whenever that might be … tomorrow or in a week or next year), you can worry about the bug. Anyone wondering why bug reports are often so bad?

But there might be a pretty simple solution: Java already can dump its heap (all objects) to a file. So what we need is a way to start this dump and add a screenshot plus a short description to it. This gets stored somewhere and when we’re done with our current task, we can return to the problem, analyze it more deeply or just zip everything up and post it as a raw bug report.

Luckily Eclipse is OSS (a.k.a “Nothing is impossible if you don’t have to do it yourself.”) See Bug 304544.


%d bloggers like this: