Grrrr arrrrh Apple, grrrr…

See here for a more balanced view.

All locks in Java are reentrant. They have to be in so that the owner of a monitor can reenter protected code. If a thread requests a lock that it already holds, it’ll be given it. Without this, a subclass couldn’t override a snynchronised method and then call the superclass method without deadlocking.

Java’s ReentrantReadWriteLock is about acquiring separate read and write locks for efficiency. For example, in the case where you may have infrequent writes but frequent reads, it may be more efficient to not synchronise all access with just one lock. Instead, ReentrantReadWriteLock can allow all read access to only block when a write is taking place. You’ll end up with multiple simultaneous reads but synchronised writes and all the reads will have guaranteed visibility of the writes.

With all Lock implementations, you specifically acquire the lock and are politely asked to release the lock within a finally block. Makes sense but gives unlock responsibility on the developer.

For some reason, common perception is that using instanceof is a bit of smell. I think its fallen in with a bad crowd and isn’t really as bad as its cracked up to be. At the very least, we should consider why its got a bad reputation.

For example, given the following, what’s clearer in the following exception handling code?

try {
    ...
} catch (InvocationTargetException e) {
    if (RuntimeException.class.isAssignableFrom(e.getCause().getClass())) {
        throw new ApplicationException(...);
    }
    throw e.getCause();
}

or

try {
    ...
} catch (InvocationTargetException e) {
    if (e.getCause() instanceof RuntimeException) {
        throw new ApplicationException(...)
    }
    throw e.getCause();
}

The Executors class has helper methods to convert from a Runnable to a Callable, presumably so you can submit a Runnable task to an executor, but it doesn’t offer the counterpart helper. Something to convert a Callable to a Runnable.

The title is a bit misleading because these guys aren’t really squaring off like Gozilla and Gigan, the projects aren’t competing and this blog isn’t really a full or fair comparison. For a start Window Licker doesn’t yet support SWT and as its name suggests SWTBot does.

My comments are really based on having a go at implementing some basic SWT support in Window Licker and adding some features to SWTBot so it shouldn’t be taken as authoritative. This entry is more of an experience report after trying to contribute to both projects. I’ll try to follow up with an API usage report when I’ve used both more with my applications.

Dave Denton were chatting recently and he was trying to convince me that less is more when it comes to maximum heap size in Java. After I finally got the point, I was aghast! Shock, horror… creating threads in Java takes up non-VM managed memory!

After running a few tests I confirmed that the lower the max heap size is, the more threads I could create. I can easily get a OutOfMemoryError when allocating memory for threads way before any real heap space is used.

The helpful message you’ll get is.

java.lang.OutOfMemoryError: unable to create new native thread

In a recent post, I was talking about a micro DSL to create a simple “find x in a list” service. The key thing here is that it defines how to look for x in the list. So the list can be a list of anything, not just a list of x’s.

Just to recap then, to find something in a list, the original client code (using a static import) looks like this.

find(needle).in(haystack)

I was recently talking about what I call micro DSLs and I thought I’d follow up with another example.

So, another example of a micro DSL I found myself writing is one of finding some object within a collection of differently typed objects. In my example, I want to find a Race object inside a bunch of calendar events objects, the finder micro DSL looks like this.

final class RaceFinder {

    private final Race race;

    private RaceFinder(Race race) {
        this.race = race;
    }

    static RaceFinder find(Race race) {
        return new RaceFinder(race);
    }

    CalendarEventEntry in(List<CalendarEventEntry> events) {
        for (CalendarEventEntry event : events) {
            if (race.getName().equals(event.getTitle().getPlainText())) {
                return event;
            }
        }
        return null;
    }
}

The way the class is built, it forces the client to use it such.

CalendarEventEntry event = find(race).in(events);

Where find is statically imported and race and events have been pre-populated.

The original version had a method in the class to do the find, in the context of this class it was harder to test the find. I had a bunch of mocks and I was testing the find function amongst other behaviours of the class. The search line looked something like this.

CalendarEventEntry event = searchForRaceIn(events);

What’s with “micro DSL”?

Why I term this a micro DSL is that it has a very specific usage (to find a race within a calendar) and it has a private constructor and public static creation method to ensure strict usage. The real thing though is the method names don’t really do what they imply they’re going to do. The in method actually does the search, but the find method doesn’t do any such thing; it creates an object.

Micro DSLs are recognisable by their tiny-domain, the way in which construction is done to ensure methods can only be called in a certain order that makes sense to the domain and badly named methods.

How do you feel about this? When its used in a tiny domain like this and when it expresses the conversation more concisely than the alternatives, I feel pretty good about it. It makes me realise its not the words (method names) that are important, its the sentences they put together. So I’m compromising on realistic method names for more expressive sentences. The fact that the class prevents you from constructing invalid sentences just makes the warm feeling grow.

Recommended Reading

• Domain Specific Languages (Addison-Wesley Signature), Martin Fowler
• DSLs in Action, DSLs in Action
• The Definitive ANTLR 4 Reference: Building Domain-Specific Languages (Pragmatic Programmers), Terence Parr

When interviewing, I often like to ask a candidate to discuss inheritance vs composition using a Stack as an example.

Example 1.

public class EvilStack<T> extends Vector<T> {
    public T pop() {
        // ...
    }
    public void push(T item) {
        // ...
    }
}

Example 2.

public class Stack<T> {
    private Vector<T> items = new Vector<T>();
    public T pop() {
        // ...
    }
    public void push(T item) {
        // ...
    }
}

Extending Vector as in example 1 weakens the encapsulation of the class. Suddenly, methods to get and insert elements at specific positions are available to clients of the stack. We move from trying to create a well behaved LIFO stack to creating a socially irresponsible monster: an EvilStack.

So I was surprised when looking at the Java source to see that java.util.Stack actually extends Vector! Naughty and things aren’t any better in Java 7 and 8.

Why didn’t Sun add a value property to the @Deprecated annotation? Instead of

@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface Deprecated {
}

which kind of implies we should do the following.

@Deprecated
/** @deprecated use {@link Foo} instead */
public class GoneOff {
   // ...
}

why can’t we have

@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface MyDeprecated{
   public abstract String value() default "";
}

which means we can use

@MyDeprecated("use Foo instead")
public class GoneOff {
   // ...
}