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> void sort(List 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…

Announcing wpmail.el

Hi Planet Emacsen, and thanks Edward!

It was only in June this year that I started to write Emacs Lisp. The first extension I wrote is wpmail.el, which I published on github but didn’t announce as I wasn’t quite happy with it. Since then, I hacked some more on it and it’s in a better shape now, so here’s the obligatory blog post.

From the file header:

An Emacs extension to make posting by e-mail to the wordpress.com blog hosting service http://www.wordpress.com easier. It might work with other wordpress installations, which I have not tried. For more information about posting to wordpress by e-mail see the support page http://support.wordpress.com/post-by-email/.

Documentation is a bit lacking, but here’s the gist: start a new post, possibly from the region or the buffer, with wpmail-new-post or wpmail-new-post-here. Send it with wpmail-send-post when you are done. wpmail will prompt for title and category; it will propose some titles that you can see via M-n, and it auto-completes the categories in wpmail-categories. See the documentation of these functions for details.

You can write your posts in Markdown format http://daringfireball.net/projects/markdown/ if you have markdown-mode http://jblevins.org/projects/markdown-mode/ installed. Set wpmail-markdown-command to your Markdown converter and posts will be converted to HTML when sending them.

I have the feeling that the documentation could be clearer. This is probably due to the fact that while I was writing wpmail.el, my ideas about the best way of using it changed.

Initially, I made it so that the very start of a blog post would be calling wpmail-new-post. It would visit a new file in wpmail-posts-dir and you’d start writing. This requires wpmail to be in charge. Then I realized that it could be less intrusive and added wpmail-new-post-here. It simply turns your current buffer into a blog post by adding a title and the wordpress shortcode directives like “status draft”. Otherwise, it’s up to you what to do with the buffer.

It works pretty well for me now, so I’m not gonna change it around again for myself anytime soon. I’d be happy about suggestions, though!

In the latest version, I also managed to get around two wordpress bugs. One was that <pre><code>, Markdown’s default markup for verbatim blocks, was being garbled. WordPress.com’s support was very helpful and the problem is now fixed. The other is that I remove single line breaks before sending, because while wordpress mostly ignores them (as you should in HTML), it seems to turn some into <br/>.

I hope it’s useful for someone. Let me know if that’s the case!