Until recently, I used an Iterator to traverse Lists. But when a requirement to traverse a list backwards crossed my desk, I (finally) went looking for something better. I suppose it took a new requirement for me to open my eyes wider because right there, in the same package, is ListIterator. A ListIterator allows you to:

1. traverse a list in either direction
2. modify the list during iteration
3. obtain the iterator’s current position in the list

IMO, the best feature of ListIterator is modifying the list during iteration. For example:

ListIterator<BizItem> iter = mylist.listIterator();


while (iter.hasNext()) {


BizItem next = iter.next();

if (next.isTooOld()) {

iter.remove();

// or iter.set(new BizItem());

}

}


<c:url value='/myapp/JustDoIt.htm' var='myHref'>
<c:param name='<%=WebParam.foo.name()%>' value='1' />
<c:param name='<%=WebParam.bar.name()%>' value='2' />
</c:url>
<a href="${myHref}>Just Do It</a>

…which results in the following HTML:

<a href="/myapp/JustDoIt.htm?foo=1&bar=2">Just Do It</a>

To retrieve the parameter values from within the controller, simply use the enum:

String foo = request.getParameter(WebParam.foo.name());
String bar = request.getParameter(WebParam.bar.name());

The best part is compliance with the DRY principle. The parameter names are uniform and not duplicated through out the web application making it easy to both search for usage and rename parameters.

Thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.

So, you’ll appreciate how surprised I was to receive such an error when I modified the signature on a service method and clearly was using the new method appropriately in my webapp. Service module compiled cleanly? Check. Service module installed in the Maven repo? Check. Webapp picking up newly installed service module from Maven repo? Check. WTF!?

And then, Eureka! I had split a bigger module containing transactional and data access objects into respective “service” and “DAO” modules in the past. Like any divorce, it got messy when the “assets” were divided between the two. An interface was moved to “service” but also remained behind in “DAO”. The webapp was compiled against a newer “service” interface, but at runtime the legacy “DAO” was resolved by the webapp via the classpath resulting in a mid-air collision. BAM!

http_request.onreadystatechange = nameOfTheFunction;

where nameOfTheFunction is an anonymous function that should look something like this:

if (http_request.readyState == 4) {
// good to go!
} else {
// still waiting...
}


The different types of states include:

• 0 (uninitialized)
• 1 (loading)
• 2 (loaded)
• 3 (interactive)
• 4 (complete)