It is commonly admitted that dynamic languages are usually more flexible and permissible than static ones. On the other hand, another recognized fact about dynamic languages is that they provide more ways for you to write buggy software if you don't pay enough attention and don't play by the rules.

For instance, I recently came across a nice bug in a web application making heavy use of Spring 2.0.2, JSP 2.0 and JSTL. Here is a piece of code that closely resembles the original code.

...

<%@ taglib prefix='c' uri='http://java.sun.com/jsp/jstl/core' %>
<%@ taglib prefix='spring' uri='http://www.springframework.org/tags' %>

...

<ul>
<c:forEach items="${someValues}" var="value" varStatus="status">
	<li>${status.index}. ${value}</li>
</c:forEach>
</ul>

...

<spring:bind path="address.zip">
	<c:if test="status.error">
		<c:out value="The ZIP code is not properly formatted." />
	</c:if>
</spring:bind>

...

Can you spot it? Ok, it might not be immediately clear what the problem is, but remember that the JSP Expression Language is a dynamic language, and thus, variables are weakly typed. The problem lies around is the status variables and here is why. In the JSTL forEach loop, we are defining a page-scoped variable named status that will keep track of the loop iterations and provide some useful information about each iteration, such as the iteration index, whether it is the first or last iteration, etc. At the bottom, we are using the bind tag of the Spring tag library, which allows to detect whether the value of the property identified by the path attribute (i.e., address.zip) could not be validated properly.

Now the thing is that the bind tag implicitely defines a new page-scoped variable, named... status, too, which provides some information about the validation of the property, such as whether the validation failed for instance (using the status.error property, etc). The error that we were seeing in the browser was along the lines of:

javax.servlet.jsp.JspException: javax.servlet.jsp.jstl.core.LoopTagSupport$1Status

Very explicit as anyone can judge. In the end, the problem was that the first status variable is of type javax.servlet.jsp.jstl.core.LoopTagSupport$1Status, while the second is of type org.springframework.web.servlet.support.BindStatus and those two types share nothing in common. After careful debugging, we could see that the cause of that JSPException was a ClassCastException, which is a typical exception raised when a weakly typed language (i.e., the JSP expression language) is being transformed into a strongly typed language (i.e., Java). So one solution here consists of renaming the first status variable using another identifier, because there is no way to override the name of the second status variable provided by spring:bind, probably one of the few thing you cannot customize in Spring ;)

For the record, the Spring 1.2.2 codebase used to explicitly cast the status variable to the org.springframework.web.servlet.support.BindStatus type, which would cause unavoidable ClassCastExceptions being raised (see SPR-1140 for more info). This has been fixed in Spring 1.2.3 and starting from release 2.0.4, any status variable available in the page or request scope is saved and re-exposed after the tag body has been evaluated (more info)

I hope this post will help other people not fall into the same nasty trap.