JavaOne 2011 Presentation Slides, Notes, Photos

JavaOne 2011 was last week in San Francisco. I gave an updated version of my “Coin In Action” talk. It seemed to be pretty well received; thanks to all who attended. Slide sets have started appearing on the JavaOne 2011 content catalog but for some reason the slides from my presentation haven’t been posted yet. I’m posting them here for download. Note that a significant portion of the talk was a demo in NetBeans. Some slides that follow the general outline of the demo are at the end of the slide deck in the section entitled “Backup Slides.”

I gave the talk in the big keynote room, which had the full video setup. A bunch of the JavaOne talks were recorded and have started to appear at parleys.com. My talk hasn’t been posted yet, though. I think the video editing might take a while. From what I understand, a few additional talks per week will be posted to parleys.com, so it might take a while to post mine (if it gets posted at all). I’ll post again here when the video for my talk is posted. Or, let me know if you see it before I do!

I’ve also posted some photos from JavaOne on my Flickr stream.

Here’s a followup comment on some issues raised with the code I showed during the talk. The question was about the “original code” I showed during the presentation:

JarFile retrieve(URL url) throws IOException {
    InputStream in = url.openStream();
    OutputStream out = null;
    File tmpFile = null;
    try {
        tmpFile = File.createTempFile("jar_cache", null);
        out = new FileOutputStream(tmpFile);
        int read = 0;
        byte[] buf = new byte[BUF_SIZE];
        while ((read = in.read(buf)) != -1) {
            out.write(buf, 0, read);
        }
        out.close();
        out = null;
        return new JarFile(tmpFile);
    } catch (IOException e) {
        if (tmpFile != null) {
            tmpFile.delete();
        }
        throw e;
    } finally {
        if (in != null) {
            in.close();
        }
        if (out != null) {
            out.close();
        }
    }
}

During the Q&A section of the talk I had a question from the audience regarding closing the out variable and then setting it to null. I wasn’t entirely sure what the questioner was asking, but I said that setting it to null was a technique for communicating between the try-block and the finally-block. In the sample code, this doesn’t do much other than avoid calling close() a second time. This usually isn’t a problem, as closing a second time usually isn’t harmful. But in more complicated cases you might need to do cleanup differently depending upon whether or not the operation succeeded.

After the formal Q&A portion of the talk a few audience members gathered up near the stage to ask followup questions. A second questioner said that his interpretation of the first questioner’s question was, since the finally-block is always going to close out, why bother closing it at all in the try-block? In response (as I was busy packing up my stuff) I mumbled something about this being a simplified example for  talk, and the actual original code might not have been amenable to such a simplification.

Now that I have had a chance to think about it a bit further, the correct answer is that the try-block must close out before it creates the JarFile instance, in order to ensure that all bytes written to out are flushed properly to tmpFile. If out were not closed, the JarFile creation might see partially written contents in the temporary file, leading to an error. The out stream would eventually be closed by the finally-block, avoiding a leak, but not necessarily avoiding an error creating the JarFile.

Of course, the whole point of the talk is that these details are exposed to programmers in Java 6 and earlier. By using Java 7’s File.copy() utility and the try-with-resources statement, these details are abstracted away, resulting in cleaner and shorter code.