driscoll's Blog

A quick introduction to the Groovy language (part 2)

In my previous post, I started with a simple Java program (which also worked in Groovy), and slowly stripped out the cruft until I was left with the following Groovy script:

def sayHello(name) {
    println("Hello $name!")
}
def name = 'world'
sayHello(name)

Now, let's add a little change to use an array.  Since Groovy is a rough superset of Java, you might be tempted to do something like:

def sayHello(name) {
        println("Hello $name!")
}

<strong>String[] names = {"SintSi", "Kaitlyn", "Keira"}

for (String name : names) {
    sayHello(name)
}</strong>

But this won't work.  This is one place where Java syntax differs from Groovy's. To create a static array, you'd instead do:

def sayHello(name) {
        println("Hello $name!")
}

String[] names = <strong>["SintSi", "Kaitlyn", "Keira"]</strong>

for (String name : names) {
    sayHello(name)
}

As before, we can eliminate the type declarations:

def sayHello(name) {
        println("Hello $name!")
}

<strong>def</strong> names = ["SintSi", "Kaitlyn", "Keira"]

for (<strong>def</strong> name : names) {
    sayHello(name)
}

But a more Groovy way of doing the same thing would be to use the "in" keyword:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

for (<strong>name in names</strong>) {
    sayHello(name)
}

Note that under the hood, this code is no longer creating an array - rather, Groovy is (invisibly) creating an ArrayList.  This gives us a number of new options - for instance, sorting:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

<strong>names.sort()
</strong>
for (name in names) {
    sayHello(name)
}

You can also add and remove entries to the list, like so:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

<strong>names += 'Jim'
names -= 'SintSi'</strong>
names.sort()

for (name in names) {
    sayHello(name)
}

But this still isn't the way that many Groovy coders would do it. They'd probably use the built in method each, which takes a closure as an argument.  If you aren't already familiar with closures (I knew them already from JavaScript), they're similar in many ways to method pointers.  And you might as well start learning about them, they're coming to Java (finally).  To use a closure, you define it using enclosing curly braces, and you can call it with the call method, like so:

def sayHello(name) {
        println("Hello $name!")
}

<strong>def clos = {name -&gt; sayHello(name)}
clos.call('world')</strong>

This will print "Hello world!".  Note that if you're trying this in groovyConsole, you'll see an additional value at the end - this is because Groovy scripts always return the last value as the return value, and groovyConsole is showing you the value of the names ArrayList.  In this example, the "name ->" preamble defines a single parameter that the closure takes.  Now let's use the closure with the each method:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

def clos = {name -> sayHello(name)}
<strong>names.each(clos)</strong>

Under the covers, names.each is iterating through the collection, and passing each value to the closure as the first parameter, just as in our previous example.  We can simplify this by creating the closure in place.  And since in Groovy, method parenthesis are optional when the method takes one or more parameters, we can say:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

<strong>names.each {name -&gt; sayHello(name)}</strong>

Which is pretty darn readable.  One more thing:  by default, the first parameter of a closure is named "it".  So, you could instead say:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

names.each {<strong>sayHello(it)</strong>}

That's it for now. If you've followed along so far, you've gotten more than enough Groovy under your belt to deal with anything you might see in my coming posts, as well as being able to say "Sure, more or less", when someone says "Do you know any Groovy?"

(As usual, this article is cross posted on my main blog site.)

DSLs with Groovy JavaOne talk

I've been neglecting my blog, but just a quick note to mention that my latest talk at JavaOne, DSLs with Groovy, is posted up on Slideshare.

The talk's designed for someone with no significant Groovy experience (unlike most Groovy DSL talks), so if it's interesting to you, check it out.

I'm hoping (but not promising) to turn the talk into a series of Blog entries in the coming weeks.  So if you want, just wait, and I'll send you explanations in more digestible bits and pieces in the coming weeks.

(As usual, this entry is cross posted to my main blog site.)

HTML5 Semantic Tags

Over the weekend, I was reading Mark Pilgrim's great book on HTML5 - and when I got to the part about the semantic tags, I thought it might be worth a quick mention.

In case you've missed out on HTML5 in general (and don't want to take the time to read that book I linked above), the idea behind semantic tags is that many sites use div blocks to mark out the same kinds of content, over and over. Content like headers, footers, and nav bars. Changing straight <div> tags to tags like <header>, <footer>, and <nav> is granting these tags semantic meaning, hence the name - semantic tags.

Semantic tags are a great idea. They offer a lot advantages over plain vanilla divs, especially for screen readers... but support in IE is pretty broken... The essential problem is this: unlike all other major browsers, IE doesn't know how to style unknown tags. So the following code won't work:

<style>
    .border {
        border: solid black;
    }
</style>
...
<section class="border">test3</section>

Ah, I hear the more informed folks in the audience say, there exists a library to fix this problem: the HTML5 Shiv. You can use it like so:

<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

This simple script will allow styles to be placed on unknown tags in IE... So, that's a good start, but there are a few problems with it. For one thing, it relies on JavaScript, so if JavaScript is disabled, your styling will fail catastrophically. Similarly, applying print styles may not work, since JavaScript won't necessarily be run as part of the print process (note: I haven't tested this fully, but that's sure what it looks like in brief testing). There are reports that nesting seems to mess stuff up applying styles correctly, but my testing hasn't found anything broken in this way that isn't already broken in IE's CSS support.

Of course, there is a way around even that: If you are running JSF or some other server side processing on your backend, you could do User Agent detection, and emit <div>'s to IE and the semantic tags to all other browsers. Then, by styling the tags solely with classes and ID's, it should be possible to make something that gets around the client side issues. Here's a section from a component that does just that.

@FacesComponent(value = "navtag")
public class NavTag extends UIComponentBase {
    
    @Override
    public void encodeBegin(FacesContext context) throws IOException {
        boolean isIE = false;
        UIComponent component = getCurrentComponent(context);
        String style = (String) component.getAttributes().get("style");
        String styleClass = (String) component.getAttributes().get("styleClass");
        ResponseWriter responseWriter = context.getResponseWriter();
        String ua = context.getExternalContext().getRequestHeaderMap().get("User-Agent");
        if (ua != null && ua.contains("MSIE") && !ua.contains("Opera")) {
            isIE = true;
        }
        if (isIE) {
            responseWriter.startElement("div", null);
        } else {
            responseWriter.startElement("nav", null);
        }
        responseWriter.writeAttribute("id", getClientId(context), "id");
        responseWriter.writeAttribute("name", getClientId(context), "clientId");
        if (styleClass != null) {
            responseWriter.writeAttribute("class", styleClass, "styleClass");
        }
        if (style != null) {
            responseWriter.writeAttribute("style", style, "style");
        }
    }

Should JSF add these tags to JSF 2.1? I'd love to hear your comments, below...

IE, Memory Management, and You

In a recent blog, commenters took me to task for a perceived IE 6 memory leak. It wasn't actually there (they were wrong), but in attempting to prove myself right, I found a couple of memory leaks under IE in JSF's Ajax support. Since I just spent a week learning how all this functioned, I thought I'd set it down so that others could learn from my efforts.

Now, none of the information that I'll present here is new - it's been discussed among Ajax programmers for at least the last 4 years. If you're a web guru, it's likely that you're not going to learn anything new here (thought I'd welcome any additional information and corrections). But at least a couple of the points I'll illustrate below are either poorly communicated or misunderstood. I'll include a number of links at the end of this article. There are also very significant differences between IE 8 (which mostly works), IE 7 (which is bad), and IE 6 (which is just awful). I'll try to point out the differences as they matter for each.

Tools

First - use the right tool for the job: In order to spot leaks, you'll need to download a tool that can detect them. By all accounts, sIEve is the way to go. It uses IE itself, and introspects to get it's data. The UI is pretty primitive, but I can't recommend it enough - it's truely invaluable. Since it uses IE for it's work, you'll need to run it on a machine that has IE6 installed - presumably in a VM. You'll also want to have it running on a machine that has IE 7 and IE 8 as well, just to be sure. XP fits nicely on a VM that runs on my Mac, and this is how I use it.

Cyclic Leak

Now that that's out of the way, it's time to talk about the very worst of the memory leaks in IE - the dreaded cyclic reference, which the commenters thought that I'd committed. Under certain conditions, IE 6 will "leak" DOM nodes, retaining them, and the javascript objects that point to them, until the browser is either shut down, or crashes entirely due to lack of memory. Ugh! To understand how this happens, you really only need to know two things:

1. IE 6 (and 7!) reportedly has very primitive garbage collection using reference counting
2. There are two memory spaces in IE, one for JavaScript, and the other for the DOM, and they don't communicate well.

What could go wrong? Well, lots. The commenters thought that the rule was: A leak will occur if any reference is made in JavaScript to an element that isn't eventually set to null. That's close, but not quite correct. The real rule is: A leak will occur if the JavaScript code contains any reference to the DOM that isn't released in some way, either by going out of scope or being explicitly unset.

When IE 6 sees a JavaScript variable that is pointing to something in the DOM (typically, an element or node), it will record that reference, and not collect it - even when you surf over to a new page. And the DOM won't be collected, since there's a reference to it from JavaScript. These two objects, and all the stuff that references them, will stick around until shutdown. In IE 7, the geniuses at Microsoft saw the bug, and said "Hey, I know how to fix that, let's garbage collect everything when we leave the page.". Nice improvement, but it still doesn't fix the bug, since if you're developing a page that is designed to be used for a long period of time (like many page-as-application apps are now), it'll still crash the browser. Apparently, they saw the error of their ways eventually, since this behavior is no longer present in IE8. (All this is confirmed by my testing with sIEve.)

So, in the example that had in my previous blog, there was no memory leak, because the variable that pointed to the element eventually went out of scope. So - how to you create variables that don't go out of scope? The easiest way is to put them in an object - this was the leak that I eventually found in JSF. The fix there was to null out the object manually. But there's another, more insidious way to create an object - create a closure. That creates a function object implicitly under the window object, and that will never go out of scope. But the key thing to remember is that you need to be aware of when things go out of scope when coding in IE, and act accordingly.

But wait! There's more

If that was the only problem, life would have been fairly easy for me the last week. But that's not the only bug that the Web Wizards of Redmond chose to deliver to their unsuspecting consumers. There's another bug in IE (again, only in IE 6 and 7 - IE 8 appears to have fixed it per my testing), which also leaks DOM nodes that aren't cleaned up until you leave the page. Apparently, when the IE DOM receives a call from the removeChild or replaceChild functions, it doesn't actually, err, remove the nodes. It just leaves them there, hanging around the DOM like party guests that don't have the sense to leave after the host has started handing out coats. While these nodes will eventually be cleaned up when the user leaves the page, this still causes problems for page-as-app programs, as in the cyclic leak for IE 7, above. While the removeChild call is fairly notorious for this, I had to find out about replaceChild with my own testing (though I did find a few obscure references once I went looking for it).

That means that instead of saying node.parentNode.replaceChild(newNode, node), you instead should say something like: node.parentNode.insertBefore(newNode, node); deleteNode(node); (with an appropriate if statement for isIE(), and a deleteNode function that doesn't use removeChild). And instead of saying node.parentNode.removeChild(node); you instead are reduced to coding something like: node.outerHTML = ''; (again, with browser check). Except that when you combine that with IE's horrible problems with manipulating tables, it may fail. So instead, you're probably better off with something like this:

<pre> 
                var temp = document.createElement('div');
                try {
                    temp.appendChild(node.parentNode.removeChild(node));
                    temp.innerHTML = ""; // Prevent leak in IE
                } catch (e) {
                    // at least we tried
                }
                deleteNode(temp);
</pre>

Hopefully you found this description of IE's Memory "Management" useful. Here's a few of the links that I used for research, that I found the most helpful.

• sIEve - the tool you should already have.
• Quirks blog link roundup of memory leak info.
• Microsoft MSDN article on the topic. Useful, even if it insultingly implies that it's your fault the browser is leaking.

As always, I look forward to any comments. Especially about this topic - I'm far from expert in this area.

UPDATE: John Resig just posted about a very interesting looking tool. Haven't checked it out yet, but if it's got him excited...