It just took me less than half an hour to upgrade to WordPress 2.0, the latest version of the blogging software I’m using. I’m impressed with backwards compatibility. Unfortunately, the Textile plugin (which enables you to format text without HTML tags) does not seem to work properly anymore, so mosts of my previous posts are now somewhat malformed. Also I had to switch off the visual editor; my code samples came out looking pretty bad. My modified version of the Now Reading plugin (including a Favorite books section) still works, as you can see. I had hoped for a lot more options to configure and checkboxes to click on and so on, but the administration screens haven’t changed that much, apart from a visual update. Okay, back to blogging!

Someone on our (Java) project team has so fallen for Ruby that he is now trying to force the Java code into Rubyesque patterns. He has found an ally for this in the Commons Collections Closure interface. What he seems to want to do in Java is the equivalent of:

sum = 0
list.each { |item| sum += item.amount; }

The Commons Collections Closure class looks like it will help out here, but it won’t. The following code will not compile, because sum must be declared final; and if you do that, you may no longer modify it inside the closure:

CollectionUtils.forAllDo(items, new Closure() {
    public void execute(Object o) {
        Item item = (Item) o;
        sum += item.amount;
    }
});

But then, Closure was defined with a restriction to begin with. If you add the ability to receive parameters beforehand, like this:

public abstract class MyClosure {
    public Object[] params;
    public MyClosure(Object... params) {
        this.params = params;
    }
    public abstract void execute(Object o);
}

then you can send the ‘outside’ variable, sum, to the closure constructor; so it can be used inside the closure:

Object[] result = forAllDo(items, new MyClosure(sum) {
    public void execute(Object o) {
        Item item = (Item) o;
        params[0] = ((Double) params[0]) + item.amount;
    }
});
sum = (Double) result[0];

The new forAllDo needs to return the closure’s parameters after looping, but is rather straightforward for the rest.

Of course, it’s still a long way from Ruby’s simple syntax. Also I wonder how much patience constructs like these will require from the people that will be maintaining this code. After all, the usual way of doing this in Java is just iterating over the collection’s items. But I guess it’s good to look at your coding habits from another point of view now and then.

Beginning bloggers can often be recognized by their fixation on web server statistics. I don’t mind admitting that I’m no exception. It’s just as satisfying to see that people read my ramblings, as it is to see people use a computer program that I wrote. Besides, the stats can show you some very interesting information, like which posts are popular, and what other sites refer people to this blog. But what’s most intriguing, is the search words some people used that lead them here. With some search words I really wonder how they could have led here, and if the posts here ever gave people the answers they were looking for. (Then again, I guess that’s the beauty of the web: you usually find what you’re looking for, but more often you find ten other things you weren’t after but are still interesting enough to look into.)

For example, how about the person that asked his search engine of choice, literally, “did sauerkraut come from switzerland?” Why did they want to know? Was the answer ever found? Does it really matter where it comes from? Personally, I would say straight away: sauerkraut comes from the Alsace region in France. The best sauerkraut I’ve ever tasted, anyway. But sauerkraut is eaten in many places, and many varieties. In Holland it’s usually mashed with potatoes, baked lardons mixed in, and served with smoked sausage. We had braised cabbage in Slovenia, which looked a lot like sauerkraut but wasn’t sour at all. According to Wikipedia, sauerkraut originated in China. Strange, it’s never on the menu at the Chinese takeaway’s…

Sauerkraut-like cabbage on the Ljubljana market

Continue Reading »

As a child, I was first introduced to French cheese by the man behind the counter in our local grocery store. He offered my mom and me a slice of Brie on a cracker. It wasn’t the best of acquaintances. I wasn’t a big fan of (Dutch) cheese to begin with, and this was just more smelly and more gooey.
Some years later in life, I got a proper introduction by the woman who is still my cheese guru. She could happily have dinner eating nothing but bread, some salad, and loads of cheese. Foul, smelly, stinking cheese — that more and more often began to taste not so bad, actually. I never saw her eat Brie. (Last time we met her she served us goat’s Brie but I don’t think that counts. After tasting it I realized that I’m still far from being a fearless cheese eater.)
The best tip she gave us recently, was to buy Coulommiers cheese. She did say to buy it at the market in the village nearby where she lives (in France); but during our last visit to France, we weren’t there on market day, so we skipped and bought some in the supermarché to take home. Bringing cheese home from France is another mixed pleasure. Every time I open the fridge, a horrible stench gusts out, best resembling the smell of fresh manure. For some reason, cheese bought here in Holland never smells that bad. Maybe that’s why it doesn’t taste as good, either.
The Coulommiers tastes like Brie with a fierce kick (it’s actually from the Brie region, so technically it is a Brie). I like it best straight from the fridge, that’s soft enough for me — but my cheese guru will disapprove. According to her, cheese should be taken out of the fridge at least an hour before eating it. I guess I still have issues with gooey things…

A picture of the Coulommiers still left in our fridge. You can almost smell it. Note the ‘au lait cru’ sign on the package; unless you’re pregnant, don’t buy cheese without it, or it will (usually) taste as bad as it smells.

In last month’s discussion started by Martin Fowler’s article on humane interfaces, some people mentioned Smalltalk’s method categories. These categories supposedly serve to bring order to classes containing large number of methods. I wonder if something like that would work for Java. (Personally, I wouldn’t call them ‘categories’, as categories imply that you can assign multiple categories to a method as well as multiple methods to a category.) For example, you could have:

public class String {

    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

    section testers {
        public int compareTo(String anotherString) {
            // ...
        }
        // ...
    }

    section mutators {
        public String replace(char oldChar, char newChar) {
            // ...
        }
        // ...
    }

    section finders {
        public int indexOf(String str) {
            // ...
        }
        // ...
    }

    // ...

}

The section names would not be used anywhere else in the code, so you don’t use "text".finders.indexOf("e"). Their use would be limited to sorting method names in IDEs, JavaDoc etc. So it would make sense to add JavaDoc to the sections, like this:

public class String {

    /**
     * Groups methods retrieving parts of the String object
     * or its attributes.
     */
    section getters {
        public char charAt(int index) {
            // ...
        }
        // ...
    }

One possible functional use for sections would be to allow access modifiers to sections, so you could have a public section businessMethods and a private section privateMethods.

There would have to be additional rules about inheriting sections in subclasses, using sections in interfaces, having methods outside sections, naming standards for recurring types of sections and such things.

The question is: does Java need something like this? The String class isn’t that huge, doesn’t have hundreds of methods like Smalltalk classes seem to have (note to self: read Smalltalk primer). I was triggered, actually, by a comment earlier on this blog, about the DefaultOWLIndividual class. It’s an example of a Java class that does have 300+ methods. A class like that would certainly benefit from (inherited!) class sections. I’m sure there are many more examples of large classes like this one.

But even if a class is not that humongous, even if it only has 10 or 20 methods; wouldn’t it still make the interface design more clear and structured if it had sections? It could also show better the intended use of the methods in the class (business methods vs. private methods). So I think sections could be a useful addition to the Java syntax.