Elsewhere: Java generics

This one is basically a write-up of a collection of links about Java generics. Yes, I know, it doesn’t get any more boring. Every Java developer knows this by now, and the cool kids have moved to Scala and Clojure. (I’m working on it, too.) But at work I kept seeing that while the idea is simple, using generics in practice in a useful way is not easy for beginners. So I started tidying up a few bits and pieces I had written for colleagues and had that in my drafts for over a year now, and as I think it’s at least a collection of the best references about generics, here it is.

Let me get it out of the way first: every Java developer should know the Generics in the Java programming language tutorial by Gilad Bracha. Definitely study this first, and that might be enough for most people.

If you’re like me and need another round of explanations and examples to fully get the corner cases, Brian Goetz’s two articles on developerworks are great.

The second article addresses the question

Because the language supports both upper- and lower-bounded wildcards, how do we know which one to use, and when?

Goetz answers

There’s a simple rule, called the get-put principle, which tells us which kind of wildcard to use. The get-put principle, as stated in Naftalin and Wadler’s fine book on generics, Java Generics and Collections (see Resources), says: “Use an extends wildcard when you only get values out of a structure, use a super wildcard when you only put values into a structure, and don’t use a wildcard when you do both.”

Read the article if that concerns you at all, it’s very useful. I particularly like his clear explanation and example for the less often used lower-bounded wildcard:
public static <T extends Comparable<? super T>> void sort(List<T>list) { ... }

Goetz explains the idea behind the wildcard in the example like this:

[…] rather than restricting the domain of sort() to lists whose elements are comparable to themselves, we can go further — we can sort lists of elements that know how to compare themselves to their supertypes, too.

Alternatively we could say the Comparator must be able to compare at least T – if it can compare more, i.e., more generic types, we’ll take that as an added bonus.

Finally, let’s be balanced and mention the big shortcoming of Java generics: the type erasure, i.e., that the generic types are erased by the compiler and are not available at runtime. So, if you have a List and cast it to an untyped List, you can then insert any old Object into it. Mike Stone explains this in detail.

Land of Lisp

I’m pretty excited about an upcoming book, Conrad Barski’s Land of Lisp. The book will teach Lisp through implementing and refining a couple of games, and it will feature a back story told in lots of cartoons. Sounds like fun!

The publisher now has a video recording of Conrad’s presentation at Philly Lambda online. I watched it last night, and am even more intrigued now. Conrad shows some awesome comic panels and some really interesting code. Besides hilarious games such as Grand Theft Wumpus, lots of other software from a web server to an SVG generator will be implemented. One game will be refined in four steps, from a C-in-Lisp-syntax kind of stateful, iterative style to a truly lispy style using macros.

I had the pleasure to meet Conrad at a FringeDC meeting in September, and had a great evening with the fringers. (Not surprisingly, Conrad founded the group; not to mention created the lisperati.com site and all its content and drew the Alien Lisp mascot.) As you might see in the video, Conrad is a witty and unpretentious guy and I’m sure it will show in the book.

Java is pass-by-value

Does the Java parameter passing follow pass-by-value or pass-by-reference semantics? For primitives, it must obviously be by value, since we don’t have any references. For objects, you can find a large number of discussions on the net, some quite heated. Today it came up once again on Hacker News, as a link to Scott Stanchfield’s Java is Pass-by-Value, Dammit!.

The answer is absolutely clear, as Scott correctly points out. Java passes the object references by value. This is not the same thing as passing the references directly, and it’s not the same thing as passing the objects as data, i.e., as deep copies. The code sample below shows why the distinction is important.

I only write this to make one more small contribution to the enlightenment of Java programmers, and to highlight a piece of code from the comments of the HN discussion because it’s probably the simplest way of clearly demonstrating the truth of Scott’s article.

public class Test
{
    public static void main(String[] args)
    {
        Object x = null;
        makeString (x);
        System.out.println (x);
    }

    static void makeString (Object y)
    {
        y = "This is a string";
    }
}

If you execute this, you see that the reference to x cannot have been passed to makeObject.

SICP in Emacs

Most people reading this will know that Structure and Interpretation of Computer Programs (SICP) by Abelson and Sussman is one of the most well known and recommended books when it comes to core Computer Science, algorithms, and functional programming. Suffice it to say, if you want to explore these areas and enhance your programming on a level beyond knowing the latest framework, check out this book. It’s freely available online, as well as recordings of lectures the authors gave.

Now, in case that’s not nerdy enough for you, I found a version in texinfo yesterday. Complete with all graphics converted to ASCII art. Yes, kinda scary, but it rocks: have your Emacs display an info buffer with the book and a Scheme or CL REPL to play with the book’s code and work on the exercises. Just move around the book and evaluate the code snippets there. Neat!

I guess that means I have to resume my project of working through the exercises. I’m not even sure where my first couple solutions are…