Hamlet D'arcy on Mockito

A beautiful post from Hamlet D'arcy on Mockito - Pros, Cons, and Best Practices. My team at work uses EasyMock. I want to use Mockito for my next project; this post makes it an easier sell.

Getting maven dependency sources and javadocs

I found Ted Wise posting on the problem I tackled today: how to download sources and javadocs from command-line maven:

$ mvn dependency:sources
$ mvn dependency:resolve -Dclassifier=javadocs

Unsure why the discrepancy.

The error of group-think

Idris Mootee writes at Blogging Innovation about the error of group-think. My favorite quote:

I see this all the time, one smart person can make a quick decision to solve a problem, two smart persons can frame an issue better and share perspectives and ten smart persons often have no idea of what problems they are trying to solve.

I have seen this all my work life: decision-making by committee produces the proverbial camel instead of a horse.

UPDATE: Fixed article link.

IntelliJ made me $1500 trading on my portfolio today

IntelliJ made me $1500 trading on my portfolio today! No, not really. But is there anything for Java programming it won't do? I read about a "new" (new to me) feature in the IDEA blog, Referencing marked objects in expression evaluation. The post describes cools updates for IDEA X to this already cool feature.

And a picture to save (1000 - N) words:

Agile games people play

3 great agile games from the First Agile Games Conference:

• Packing Peanuts
• The Backlog is in the Eye of the Beholder
• Making Pamphlets: Kanban Game

Thank you Improving Blogs mashup!

Manifesto for Half-Arsed Agile Software Development

Courtesy of Brian Winquist, the Manifesto for Half-Arsed Agile Software Development.

More uses for Iterables

Iterable is one of my favorite interfaces in Java. I love the for-each construct:

for (final Type item : iterableOfItems)
    doSomethingWith(item);

Notice what cannot go wrong:

1. I cannot run off the end, or forget to go far enough (no off-by-one bugs)
2. I cannot forget to call hasNext() before calling next() (iterator misuse)
3. I cannot make the wrong cast or pick the wrong container type

I could go on. It is also concise and conveys programmer intention clearly, both wonderful virtues.

How can I make more use of Iterable?

Here is an example of transforming input into Iterable. First the base class:

public abstract class ResourceIterable<T, R extends Closeable>
        implements Closeable, Iterable<T> {
    private final R resource;

    private volatile boolean closed;

    protected ResourceIterable(final R resource) {
        this.resource = resource;
    }

    protected final R resource() {
        return resource;
    }

    protected abstract T getNext()
            throws IOException;

    @Override
    public final void close()
            throws IOException {
        closed = true;
        resource.close();
    }

    @Override
    public final Iterator<T> iterator() {
        return new Iterator<T>() {
            private T next;

            @Override
            public boolean hasNext() {
                try {
                    next = getNext();
                    return null != next;
                } catch (final EOFException ignored) {
                    next = null;
                    return false;
                } catch (final IOException e) {
                    next = null;
                    if (closed)
                        return false;
                    throw new UndeclaredThrowableException(e);
                }
            }

            @Override
            public T next() {
                if (null == next)
                    throw new NoSuchElementException();
                return next;
            }

            @Override
            public void remove() {
                throw new UnsupportedOperationException();
            }
        };
    }
}

And a sample using class:

public class LineIterable
        extends ResourceIterable {
    public AmpsResponseIterable(final BufferedReader reader) {
        super(reader);
    }

    @Override
    protected String getNext()
            throws IOException {
        return resource().readLine();
    }
}

The example is trivial (my actual uses are hiding sophisticated readers of data structures from network connections) but clear:

for (final String line : new LineIterable(someBufferedReader))
    process(line);

However, all use of Iterable is similarly trivial: that's the point if it. The complexity is in extracting objects from the input (though not in this example).

I prefer hard-to-write-easy-to-use code when I make libraries; easy-to-write-hard-to-use just feels lazy (the wrong kind of lazy).

Guice moving to Maven

It's not new news, but it was new to me: Maven is switching to Guice to wire itself and plugins. From Sonatype:

1. From Plexus to Guice (#1): Why Guice?
2. From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
3. From Plexus to Guice (#3): Creating a Guice Bean Extension Layer

The plugin framework is named spice inject and glancing through it's straight-forward glue between Guice and OSGi within a Maven object domain.

It looks very clean. Nice.

Large-scale refactoring

Vikas Hazrati has a nice post on large-scale refactoring on InfoQ. I'm a strangler. You?

Have tools, will code

Thanks to the benevolent JetBrains, I now have an OSS license for IntelliJ IDEA to develop an Android app. I first started using IDEA at ThoughtWorks where it quickly became my favorite development tool.

And thanks to Turbine, I have my data.lotro.com developer key! So I am ready to start an LOTRO Android App. And I've already been getting encouraging words from the LOTRO forums. Go, community!

Nexus out, Android in

My dreams of a Nexus One came to naught. But...

I now have an excellent Samsung Galaxy S with Android 2.1, and I asked JetBrains for an open-source license for their Android plugin to IntelliJ IDEA. I have plans brewing!

Hands-free Coding: Code Generation with Annotation Processors

I'm speaking at Houston TechFest on October 9! My talk is Hands-free Coding: Code Generation with Annotation Processors. Wish me luck. Here's the summary:

Have you ever written hundreds or thousands of lines of boilerplate code, or struggled to write Java idioms correctly every time? There is great way to save time and effort and use to standard code patterns automatically: Code Generation.

In this talk, I will walk you through using the JDK6 Annotation Processor API together with Velocity templates to read your Java source code and write new Java source files for you from code templates. It is magic, but magic you can understand and use to be more productive.

Let the compiler write your code for you!

Please come watch!

Lua coming to LOTRO

With Lua coming to LOTRO I may have to dust off my Lua, last used in hacking at T.o.M.E.. It will be a nice break from Java and work, and give me something nice to do for my wife who doesn't know (yet) about MMORPG add-ons.

JB Rainsberge's 10 things

Courtesy of Naresh Jain comes J B Rainsberge's list of 10 things to stop doing or he will bury you alive in a box (about 1hr30m of video), a really delightful presentation on agile.

For the impatient, the list (which is only about half the presentation):

1. Stop writing comments that describe what the code does
2. Stop working in code bases with compile errors
3. Stop insisting that writing the tests after is just as good as writing the tests before
4. Stop insisting that evolutionary design leads to poor architecture
5. Stop writing tests for "coverage"
6. Stop arguing about whether a story is done
7. Stop trying to increase your velocity
8. Stop breaking up working teams
9. Stop acting as though agile is "what the project teams do"
10. Stop telling your people to "go agile" on their own

Go watch the whole thing, and please, Stop It.

Why did Sun fail?

James Gosling tells a great tale on why Sun failed. Spoiler: the alpha particles did it.

Competition for mindshare

Mindshare is a term I rarely hear outside of business or technology magazines, but is very appropriate here. Java has long been king in the unit testing space, and though hoary, JUnit is still one of the best unit testing libraries around.

But Ruby is giving Java serious competition. I am late to the party, but just ran across metric_fu in this post. I wish I had metric_fu for Java!

In the 90s the evolving Java ecosystem was the top reason I moved from C/C++ to Java. JDK7 looks to keep Java the language on life support so it will not immediate wither away (although who came up with the name public defender methods [PDF]?). But the library momentum is not in Java's favor at the moment.

Faster, JRuby! Faster!

Paul Holser's property-binder library

Paul Holser, a fellow ThoughtWorks alum, wrote a nice library for handling properties, property-binder. More to the point, it is an example of PICA style (proxied interfaces configured with annotations), something Paul wrote about recently.

property-binder works using dynamic proxies to turn one kind of call (a typed API) into another (lookups of properties). This is elegantly done.

An alternative for situations where proxies are not appropriate is to use the code-generation facility of annotations, to write Java code for the conversion. The user of annotations cannot tell the difference: the same annotations, interfaces and static factory methods appear in both cases.

This is an interesting corner of Java, bringing together several advanced features but leaving them accessible to the caller with elementary techniques.

Tracking changing data in Java

I need to track changing data in Java. For example, say I am collecting data sets of some real world behavior, and I'd like to know what has changed between individual readings: additions, removals, changes.

I start with a single datum:

public static class Example {
    public final int index; // primary key
    public final double value; // satelite data
    public final long access; // other data

    public Example(final int index, final double value,
            final long access) {
        this.index = index;
        this.value = value;
        this.access = access;
    }

    @Override
    public boolean equals(final Object o) {
        if (this == o)
            return true;
        if (o == null || getClass() != o.getClass())
            return false;

        final Example example = (Example) o;
        if (index != example.index)
            return false;

        return true;
    }

    @Override
    public int hashCode() {
        return index;
    }
}

Reducing to essentials:

• Primary key values: different Example instances with the same index represent the same "thing"
• Satellite data: these are the measurements I want to track
• "Other" data: these are part of my data set but are not part of my change tracking

Now equals and hashCode take care of matching equivalent data so I can compare values between data sets. But I also need to know if the satellite data has changed:

public static class ExampleComparator
        implements Comparator<Example> {
    @Override
    public int compare(final Example a, final Example b) {
        final int c = Integer.valueOf(a.index).compareTo(b.index);
        if (0 != c)
            return c;
        return Double.valueOf(a.value).compareTo(b.value);
    }
}

An important point to consider: why not have Example implement Comparable<Example> instead of the separate comparator class? Read the Comparator javadocs closely: you really want equals and compareTo to agree (the discussion is good — I have a new source of bugs to comb out of my code base).

But here equals looks at only primary keys and the comparator looks at both primary keys and satellite data: they do not agree.

Having all the tools I need, time for comparing data sets (please be kind about the weak class name):

public class Differator<T, C extends Comparator<T>> {
    private final Map<T, T> items = new HashMap<T, T>();

    private final C comparator;

    public static <T, C extends Comparator<T>> Differator<T, C> newDifferator(
            final C comparator) {
        return new Differator<T, C>(comparator);
    }

    public Differator(final C comparator) {
        this.comparator = comparator;
    }

    public Changes<T> replaceAll(final Set<T> newItems) {
        final Changes<T> changes = new Changes<T>();

        for (final T item : items.keySet())
            if (!newItems.contains(item)) {
                changes.deleted.add(item);
                items.remove(item);
            }
        for (final T newItem : newItems) {
            if (!items.containsKey(newItem))
                changes.inserted.add(newItem);
            else {
                final T item = items.get(newItem);
                if (0 != comparator.compare(item, newItem))
                    changes.updated.add(new Delta<T>(item, newItem));
            }
            items.put(newItem, newItem);
        }

        return changes;
    }

    public static class Delta<T> {
        public final T item;
        public final T newItem;

        public Delta(final T item, final T newItem) {
            this.item = item;
            this.newItem = newItem;
        }

        @Override
        public boolean equals(final Object o) {
            if (this == o)
                return true;
            if (o == null || getClass() != o.getClass())
                return false;

            final Delta delta = (Delta) o;

            if (!item.equals(delta.item))
                return false;
            if (!newItem.equals(delta.newItem))
                return false;

            return true;
        }

        @Override
        public int hashCode() {
            int result = item.hashCode();
            result = 31 * result + newItem.hashCode();
            return result;
        }
    }

    public static class Changes<T> {
        public final Set<T> inserted = new HashSet<T>();
        public final Set<Delta<T>> updated = new HashSet<Delta<T>>();
        public final Set<T> deleted = new HashSet<T>();

        @Override
        public boolean equals(final Object o) {
            if (this == o)
                return true;
            if (o == null || getClass() != o.getClass())
                return false;

            final Changes changes = (Changes) o;

            if (!deleted.equals(changes.deleted))
                return false;
            if (!inserted.equals(changes.inserted))
                return false;
            if (!updated.equals(changes.updated))
                return false;

            return true;
        }

        @Override
        public int hashCode() {
            int result = inserted.hashCode();
            result = 31 * result + updated.hashCode();
            result = 31 * result + deleted.hashCode();
            return result;
        }
    }
}

It was not much effort to write Differator. replaceAll swaps out a new data set for an old one, returning how they two differed. Credit for immediately spotting that Differator is not merely thread unsafe, it is very unsafe. But this is not hard to address in a simple way.

Lastly, some tests:

public class DifferatorTest {
    private Differator<Example, ExampleComparator> differator;
    private Example item;
    private Changes<Example> changes;

    @Before
    public void setUp()
            throws Exception {
        differator = newDifferator(new ExampleComparator());
        item = new Example(1, 3.14159, 123);
        changes = differator.replaceAll(singleton(item));
    }

    @Test
    public void testFirstInsert() {
        assertThat(changes.inserted, is(equalTo(singleton(item))));
        assertThat(changes.updated.isEmpty(), is(true));
        assertThat(changes.deleted.isEmpty(), is(true));
    }

    @Test
    public void testUpdateUnimportantData() {
        final Changes<Example> changes = differator
                .replaceAll(singleton(new Example(1, 3.14159, 456)));
        assertThat(changes.inserted.isEmpty(), is(true));
        assertThat(changes.updated.isEmpty(), is(true));
        assertThat(changes.deleted.isEmpty(), is(true));
    }

    @Test
    public void testUpdateSatelliteData() {
        final Example newItem = new Example(1, 2.71828, 123);
        final Changes<Example> changes = differator
                .replaceAll(singleton(newItem));
        assertThat(changes.inserted.isEmpty(), is(true));
        assertThat(changes.updated, is(equalTo(
                singleton(new Differator.Delta<Example>(item, newItem)))));
        assertThat(changes.deleted.isEmpty(), is(true));
    }

    @Test
    public void testUpdatePrimaryKey() {
        final Example newItem = new Example(2, 3.14159, 123);
        final Changes<Example> changes = differator
                .replaceAll(singleton(newItem));
        assertThat(changes.inserted, is(singleton(newItem)));
        assertThat(changes.updated.isEmpty(), is(true));
        assertThat(changes.deleted, is(singleton(item)));
    }
}

Summary of lambda changes for JDK7

Alex Blewitt writing on InfoQ posts an excellent write up on the state of lambda in JDK7.

It is exciting to see Oracle move on this front publicly after long months invisibility. Two interesting potential features I am rooting for: SAMs and this for recursion.

Hope springs eternal in the human breast.

12 Maven tips from Johathan Wolter

Repurposing test code for production

For various reasons I often wrap the well-known logback logging library; more precisely, I wrap the SLF4J API it implements.
However, this has a strong drawback: filename and line numbers in the log which should tell me the origin of the log calls instead show me my wrapper class. From logback's perspective the wrapper is the caller; from my perspective the wrapper should be invisible.
The culprit is CallerData.isDirectlyInvokingClass(String, String). It tells logback if a given stack frame is internal to logback or from the calling application. It is static and logback has no hooks for changing its behavior. What to do?
The hack:

public class Wrapper {
    static {
        new MockUp() {
            CallerData it;
 
            @Mock(reentrant = true)
            public boolean isDirectlyInvokingClass(
                    final String currentClass,
                    final String fqnOfInvokingClass) {
                return it.isDirectlyInvokingClass(
                        currentClass, fqnOfInvokingClass)
                    || currentClass.equals(Wrapper.class.getName());
            }
        };
    }

    // Rest of class
}

Enter the clever jmockit library sitting at the high end of the testing mock library pile up (or deep end, if you prefer). Jmockit is not the easiest library to use, but is has more code-fu per line than most other swiss-army knives.
I replace the static method in logback with my own when my wrapper class is loaded. I even get a handle (it) to the original method so I may forward appropriately.
This is not my first try at a solution to wrapping logback. Nor my second. Nor my third. But it is the only one so far which:

• Works
• Looks like Java
• Is compact and limited to the wrapper class
• Can be explained to others (mostly)
• Can be maintained (by some)

I have penance to pay for pulling a testing library into production code, but I get some colleague credit for cleverness. It might even be a wash.
Do watch out for:

• Running the application right in the presence of jmockit
• The obligatory AOP warning for the "it" trick

Guicing your jars

Through the magic of ServiceLoader you can automate the wiring of your classpath components:

public static void main(final String... args) {
    final Injector injector = Guice.createInjector(
            ServiceLoader.load(Module.class).iterator());
    // Use injector here, etc.
}

For each jar or classpath component, include a META-INF/services/com.google.inject.Module file containing the class name of a Guice module which can configure the jar, e.g., hm.binkley.rice.MobModule.

This makes your jars auto-configuring. Merely including them in the classpath is sufficient to be injected into your application. You will find multibindings useful for each jar to provide a well-known list of services without them colliding.

Raw types make my head hurt

This compiles:

public static void main(final String... args) {
    final Fred fred = new Fred();
    final Integer i = fred.get(Integer.class);
}

public interface Bob {
    <T> T get(final Class<T> type);
}

public static class Fred implements Bob {
    @Override
    public <T> T get(final Class<T> type) {
        return type.cast(null);
    }
}

This does not:

public static void main(final String... args) {
    final Fred fred = new Fred();
    final Integer i = fred.get(Integer.class);
}

public interface Bob {
    <T> T get(final Class<T> type);
}

public static class Fred<Q> implements Bob {
    @Override
    public <T> T get(final Class<T> type) {
        return type.cast(null);
    }
}

But this does:

public static void main(final String... args) {
    final Fred<?> fred = new Fred();
    final Integer i = fred.get(Integer.class);
}

public interface Bob {
    <T> T get(final Class<T> type);
}

public static class Fred<Q> implements Bob {
    @Override
    public <T> T get(final Class<T> type) {
        return type.cast(null);
    }
}

And this does:

public static void main(final String... args) {
    final Fred fred = new Fred();
    final Integer i = ((Bob) fred).get(Integer.class);
}

public interface Bob {
    <T> T get(final Class<T> type);
}

public static class Fred<Q> implements Bob {
    @Override
    public <T> T get(final Class<T> type) {
        return type.cast(null);
    }
}

What is going on here?

UPDATE: Thanks to Bob Lee in the comments, I see what is going on. Using a class-level raw type results in the methods of that class also being treated as raw types, even though the type parameters of the class and method are separate. (NB — this does not apply to static methods, only instance methods.)

readlink for better scripting

Fritz Thomas solves a common shell scripting problem for me: finding where your script lives. This script saved as ~/bin/x:

#!/bin/bash
echo "$0"
readlink -f "$0"

With ~/bin in PATH produces:

$ cd ~/bin; ./x
./x
/home/where/the/heart/is/bin/x
$ cd; x
/home/where/the/heart/is/bin/x
/home/where/the/heart/is/bin/x

Just what I need! (Yes, quite an odd home directory.)

Do note the caveats for readlink(1).