The Problem

The JSTL and EL greatly reduce the amount of Java code in a JSP and as a result, can be used improve its maintainability. The EL provides a syntax for working with Java objects and allows an object’s properties to be accessed using a simple dot notation. So, for example, in order to access the size of a collection, we might assume that we could use an expression like this:

${collectionName.size}

Unfortunately this will not work. In order to access a property in this way the object to which the property belongs must be implemented as a JavaBean component and it’s methods must adhere to the conventions described in the JavaBeans specification.

In short, to read the size property of a collection, the EL requires that the collection implements a getSize method; the bad news for us is that no such method exists in the Collections API.

Hack 1 – Use Scriptlets

The most common work-around to this problem is to simply fall back to using Java in a scriptlet in the JSP instead of the EL and to cast the request attribute to a collection:

<%=((Collection)request.getAttribute("collectionName")).size()%>

This work-around produces some quite ugly code and becomes even worse when we use it as part of another expression; for example, to test the size within an if tag:

<c:if test="<%= ((Collection) request.getAttribute("collectionName")).size() == 1 %>">
...
</c:if>

Hack 2 – Provide a JavaBeans Compliant Collection Wrapper

A more elegant solution is to wrap the Collection with an object that implements the Collection interface and delegates all calls to the real collection:

public class JSTLCollectionWrapper implements Collection {
    //the underlying collection that is being wrapped
    private final Collection realCollection;

    //constructor
    public JSTLCollectionWrapper(Collection c) {
        realCollection = c;
    }

    //implement Collection interface and delegate all calls to realCollection

    //provide a JavaBeans getter method for the size property
    public int getSize() {
        return realCollection.size();
    }
}

Then in your controller class, wrap all collections before adding them to the request or the users session:

Collection wrapped = new JSTLCollectionWrapper(realCollection);
request.setAttrubute("collectionName", wrapped);

The JSTL expressions can now access the size property of the collection as the wrapper class implements this according to the JavaBeans specification:

${collectionName.size}

The downside to this approach is that it requires you write the wrapper class, and that you must remember to use it wherever you add a collection as an attribute to an HTTP request or session in your controller classes.

The Best Practice Approach

Just so long as you’re using an application server that supports JSTL 1.1 or later (and you really should be), there’s a much neater solution available: use the functions tags.
The functions tags can be used in a JSP just like any other tag library, but rather than providing tags to use, the library extends the capabilities of the EL by providing some simple functions for you to use. Here’s how you can check the size of a collection using the functions tags:

<%-- declare that we intend to use the functions taglib --%>
<%@ taglib prefix='fn' uri='http://java.sun.com/jsp/jstl/functions' %>

<%-- use it --%>
${fn:length(collectionName)}

The first line here is just a standard taglib directive telling the application server that we would like to use the functions tags. The second line illustrates how the length function can then be used to return the size of a collection.

As you can see, the syntax is pretty simple, far less intrusive than using a scriptlet, and does not require any special coding in your controller classes. It also has the added advantage that it works for arrays too, and will even return the length of a String should you need to figure that out.
This solution retains much of its simplicity even when used in more complex expressions:

So there you have it. If you’ve been trying to figure out how to work with collection’s sizes in your JSPs, or maybe you’ve just been praying that Sun would rename the size method to getSize, then the functions tag library can offer a neat and simple solution to this common programming pitfall.

Problems with adding comments

Inserting code snippets into Javadoc comments that read well in both the source code and the HTML files produced by Javadoc can be a very fiddly process. Inserting XML snippets into your documentation can make this trickier still. Read on to discover a simple technique that works equally well with both Java and XML code snippets in your Javadocs.

I recently needed to add some comments to my Java classes to show some simple cases of how they should be used in other applications.

In particuar, the classes I was developing were for use in Spring based applications and would need to be configured using XML. This is where the Javadoc tool really starts to struggle. When generating the HTML pages, Javadoc does not (by default) escape the XML characters it finds in your comments – it just copies them verbatim into the HTML it produces.

So, if you were to write a comment like this:

/**
* <p>This class should be used as follows:</p>
* <bean>
*     <property name="propName" value="propValue"/>
* </bean>
*/
public class MockObject {
...
}

you will only see the following when examining the resulting Javadocs in a browser:

This class should be used as follows:

The reason for this is that the markup has been copied directly into the HTML page. The browser doesn’t recognise the bean tag and simply ignores it.

Using the {@code … } Javadoc tag

Javadoc does provide a useful tag or adding code to comments:

/**
* <p>This class should be used as follows:</p>
* {@code
* <bean>
*     <property name="propName" value="propValue"/>
* </bean>
* }
*/
public class MockObject {
...
}

This will cause the XML within the {@code … } markup to be escaped so that the < and > characters are displayed properly. The problem with this technique though is that line breaks will be ignored by the browser and all the neatly formatted XML in our source code will be displayed on a single line by a browser.

Preserving XML Characters and Line Breaks

In order to preserve the line breaks and the XML characters, you need to use the {@code … } Javadoc tags in conjunction with HTML pre tags:

/**
* <p>This class should be used as follows:</p>
* <pre>
* {@code
* <bean>
*     <property name="propName" value="propValue"/>
* </bean>
* }
* </pre>
*/
public class MockObject {
...
}

This will produce the kind of markup we’re looking for:

This class should be used as follows:

<bean>
     <property name="propName" value="propValue"/>
</bean>

The HTML pre tags instruct the browser to respect whitespace characters and to show the spaces and line breaks. The {@code … } Javadoc tag instructs the Javadoc tool to escape the < and > characters so that they will also be displayed correctly by the browser too.

So there you have it! A (relatively) simple technique that allows both Java and XML code snippets to look as good in your Java source code as they do in the Javadoc HTML files.