Michael Nascimento Santos's Blog

November 2003 Archives

Crazy JSTL: when an empty Collection is not empty

Previously, I have promoted JSTL as an easier way to code the web tier. While I haven't changed my mind about it, I have just come accross one of its pitfalls yesterday, a few minutes after writing a blog entry about grid computing. Have you ever been in a situation code that looked impossible to be incorrect actually was incorrect? Well, it happens in many occasions, generally in the most unwanted ones - as it did yesterday, when it was around 3 am in Brazil.

Let's go straight to the point: for those of you who are familiar to JSTL, consider the following code:

<%-- Block 1 --%>
<%@ page import="java.util.Collection" %>
<%
    Object o = request.getAttribute("collection");
%>
<%= (o instanceof Collection) && ((Collection)o).isEmpty() %>

<%-- Block 2 --%>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

Assuming the first block prints true and that the Collection implementation used is flawless, what does the second block prints? true, right? Wrong! The right answer is: it depends.

Wait a minute: it depends? But how? Verbatim from the JSTL spec 1.0, section 3.8:

To evaluate empty A:
   
 If A is null, return true,
   
 Otherwise, if A is the empty string, then return true.
   
 Otherwise, if A is an empty array, then return true.
   
 Otherwise, if A is an empty Map, return true
   
 Otherwise, if A is an empty List, return true,
   
 Otherwise return false.

So, the JSTL 1.0 spec says nothing specifically about using the empty operator to evaluate Collections; it just supports the intended behaviour - the one we would expect - for Maps and Lists, and not all Collections. If you happen to have a Set implementation as your Collection implementation, for example, it won't work. The empty operator support in JSTL 1.0 is just for null, Strings, arrays, Lists and Maps, not for Sets. It's simply bad, too bad it works this way.

A good reason for people assuming it works like this is that most articles and presentations about JSTL say empty works for Collections. Just to mention a few examples, articles published at OnJava, IBM DeveloperWorks and even java.sun.com wrongly state it. But why can it simply return true although the spec doesn't mention it? Well, because it cannot be considered an omission. The spec says that otherwise, it must return false. Otherwise sadly covers Sets and any other Collections implementation that does not descend from a List. Sad, very sad indeed.

Are we doomed to look for alternatives approaches? One of them that works is using ${collection['empty']} when we are sure we are dealing with a Collection. Using a straight property access construction won't work as the property has the same name as the reserved operator. Fortunately, the Expression Language definition specified in JSP 2.0 has fixed the issue by replacing the line that mentioned List with:

   Otherwise, if A is an empty Collection, return true,

So, if you are using JSP 2.0, it's not a problem for you. However, be careful about JSTL 1.0 and this bizarre pitfall. I tried to warn you :-D

Why is everyone talking about grid computing? And what are you doing about it?

"Grid computing" - though it was quite an unknown concept till a few years ago, now everyone is talking about it. Some are saying it is everything we were missing, the next big thing. Others, as some java.net bloggers, are simply skeptical and uncertain about its practical use. But the fact is many huge companies, such as Oracle and IBM, are investing a lot of money on that - and that's a good reason to take a closer look at it.

To begin with, what is grid computing? Grid computing is about spliting your work in small pieces - or jobs, as you prefer - and assigning those pieces to different computer on the network. After they have been processed, you get them together and your main task is done. But what is the big advantage of applying grid computing?

Have you ever thought about reducing the time your Ant builds take to run? What if you could use other developers' machines to run it in parallel while they are having coffee or are out in a meeting? Wouldn't that be great? And what if you could perform parts of a specific transaction in some machines available in a cluster instead of loading one box for a minute when the user could get the response in a few seconds? Those are the kind of things that may be accomplished with grid computing in an easier way.

So, what is the Java standard for grid computing? None. Soon, there will be one and then we will have to accept it, whether we agree with the way it will be or not. If you are among the ones who hate EJBs - I don't, just gave my own suggestions previously here -, or that think that JSPs are a big mistake, stop complaining! Get involved. Talk to the ones who are defining the standard. Go to grid forums, talk to the guys at Sun One Grid Engine, move! Download one of the many implementations available, such as Globus or Sun One Grid Engine, use them, share your thoughts about it! Tell the community what you like and what you don't and why.

Grid computing will be very useful to many people in the future, but if it is not useful for you tomorrow, well, maybe that's why you didn't try to shape its future when you had the chance...

How do you teach Java?

To begin with, if you ever read any of my first blog entries, three months ago, when I had the time to write them :-P, you may have found this topic a bit unusual for a guy who likes to talk about APIs and JSRs. Well, I must say I consider both things equally important: those who just know things to themselves are not useful at all in some situations - if you have millions of lines of code to migrate and your client has a great, brilliant team, that only doesn't know Java (yet), for example - and vice-versa. But let's get back to the topic.

At Summa Technologies, my new professional home, we're not afraid of neither implementing nearly-impossible-to-write, mission critical software, nor mentoring and training teams so they are able to accomplish the nearly impossible tasks on their own. However, I must say the team I'm teaching right now is really special, in a good way. Part of them never were programmers really - they were just support team members. Others are average to very good skilled C/C++ programmers, whereas some of them have programmed in a hybrid C-based language, which is closer to Visual Basic in its essence than to C, to be fair. Finally, the last group is composed of people who simply never paid much attention to coding, but instead dedicated most of their professional lives to the analysis field.

While we generally expect the C++ programmers to perform better than the others, that's not what happens. The fact is that, generally, support team members write better code faster than most students. Why? Well, they have nothing to fight against! They don't think based on C or other language, they are able to face Java as pure Java, Java itself. That leads them to wonderful results. One of them was the first person ever who didn't know Java and was able to solve my classic "how-to-convert-this-expression-to-string" problem without doing it in an ugly, cumbersome way - which we call "gambiarra" or "gambi" for short, in Brazilian Portuguese. That made me really happy and proud of teaching them.

So, now you think the C++ or the other kind of programmers are the best after them, right? It is not that simple, actually. Some paradigms can stop most pure C and similar platform developers from producing accurate, well designed classes since they tend to write code before really understanding the problem they are trying to solve. They are used to write code, delete it as they notice it doesn't solve the problem and then rewriting it again and again till it works. When it happens, well, a considerable part of the code is just rubbish. But the analysts, well, once you tell them two or three times to stop trying to code if they don't know what they're doing, they listen to you! They spend 60% of the time thinking and 40% coding, very close to the ideal rate (80/20 for new problems).

Another common mistake programmers do: they try to think in Java! Why is it bad? They do it because they can "think" in their current programming language, since they are used to them for ages. Again, the problem is: you are not able to think in a language you don't understand! So, they must solve problems in a intermediary language, an internal analysis language we all developed as programmers and some of us forgot when we got good at our current programming language. That fact makes analysts perform better again, since this intermediary language is to them their natural language!

The last interesting fact is people find it much harder to understand object-oriented concepts than the whole language itself. Does it seem obvious to you? I think so, but the point it that, if you explain and expose a concept in every possible way, giving abstract examples they can relate to, real code examples with a few classes, draw clear and simple diagrams, make they explain the concept to you in their own words and they still can't apply the concept or even explain it to you the day after, what do you do to make them understand? I don't have a fixed answer for that question. I try to pay attention to the person so that I know what to do in that specific case. Eventually, I can get the person to understand the concept and then I am able to sleep in peace again :-D.

That is the coolest part about teaching: it makes you remember we are humans and that, no matter how common, simple, standard we look, we are unique. You cannot assume things about people. We react in unique ways. That makes us extremely beautiful pieces of design. Instances of a race, with different results for our equals implementation. We are not comparable or serializable, though. But we are all the same in essence. Belong to the same class, the same race. In fact, if we think this way, God is a far better architect than we will ever be.

This work is licensed under a Creative Commons License.