Apache announced the release of Velocity 1.5 recently, with improvements in the velocity template language, support for Java's built-in logging, better error messages, bug fixes, and more. The release notes offer more detail. It's good to see Velocity 1.5 released, after so long as what many considered to be an abandoned project. Now the question turns back into a Freemarker vs. Velocity debate - which and why?

I'm glad to see Velocity is still active, after all. The release notes include some really nice enhancements. I have never used Freemarker, but one of our big applications at my company depends largely on Velocity. The decisions were made long before I joined, but our presentation layer is almost exclusively Velocity templates and helpers/tools, and minimal JSPs.

The whole null value handling in Freemarker irks me a bit-- I understand the reasoning for forcing the end developer to handle the value, but even putting error handling into silent mode and with having undetermined sets of data for display, your error logs can quickly fill up.

The whole null value handling in Freemarker irks me a bit-- I understand the reasoning for forcing the end developer to handle the value, but even putting error handling into silent mode and with having undetermined sets of data for display, your error logs can quickly fill up.

Jacob, in FreeMarker, if the variable foo is potentially null, you can write: ${foo!} and in the cases where foo is null, the above will output nothing. IOW, the ! at the end means to coerce a null into an empty string if necessary. However, if you write: ${foo} and foo happens to be null, then it is not silently ignored, an exception is thrown. I consider this to be unimpeachably correct. (I was the one who decided that it would be like this, BTW.) The fact is that foo being null would, in a very high percentage of cases, be due to programmer error of some sort and you should want to be alerted to this. In any case, what you really seem to be advocating is for a template engine to do something arbitrary when you give it arbitrary input (a null in the data model) and I really put it to you that this is a bad idea. For example, if the value is null in your data, it may be that the correct human-readable thing to output is not an empty string, but rather, something like N/A for "not available." in this case, in FreeMarker, you could write: ${foo!"N/A"} to express this. You get N/A when the variable is null. So note that ${foo!} is actually a shorthand for ${foo!""} in the previous example. But in any case, if the value is potentially null, you must make your intent clear. There are also many cases where a value really is not supposed to be null and it is right and proper that an exception be thrown. Again, FreeMarker simply obliges you to make clear your intent as to what happens when the value is null. It does not guess and do something arbitrary for you. I put it to you that if you really really think about this, you will realize that what FreeMarker does is correct and you want it to work the other way because you got used to JSP and/or Velocity. Speaking more generally, tools that are more picky about potential errors, bringing them to your attention, are more likely to result in robust systems at the end of the day, than tools that do arbitrary things with input that is very likely to be erroneous. For more information, this is a FAQ entry on the freemarker.org site. http://freemarker.org/docs/app_faq.html#faq_picky_about_missing_vars

This is an issue in Velocity as well. If you iterate a collection, and you have an entry that contains null, velocity will output the last value again(!) This is quirky to say the least...

is now configurable. the default is still "quirky", but you can now set: directive.set.null.allowed = true in your velocity.properties, and it will work more sensibly.

Its great to see the Velocity 1.5 release out. Congratulations to the Velocity development team. Velocity is one of those old time great frameworks. It really hits the sweet spot in terms of easy of use and functionality. Its hard to beat. Its also good to see Velocities development cranking up again. Looking forward to new features in Velocity 1.6. Also if you are considering developing web apps with Velocity I would recommend you take a look a Click Framework, as it uses Velocity as the rendering engine. regards Malcolm Edgar http://click.sourceforge.net

Havn't got chance to use velocity yet, I have been using freemarker wid webwork, n its gr8. May any one tell me, why velocity is better thn freemarker ? sudhir http://www.jyog.com

Velocity is easier to learn than FreeMarker. However FreeMarker is more powerful than Velocity, i.e. its got more features. One of the reasons I like Velocity is that the language directives standout in HTML. Where FreeMarker syntax looks more like JSP/XML markup, which is harder to see distinguish HTML. In FreeMarker you can use [LIST] [/LIST] syntax, but I personally find it too heavy. Take a look at this Velocity HTML example below. Note how you dont need to learn JSTL or a tag library to understand what is going on: #if (!$order.lineItems.empty) Name Quantity Total Price #foreach ($lineItem in $order.lineItems) $lineItem.name $lineItem.quantity $lineItem.totalPrice #end #else No items have been ordered. #end regards Malcolm Edgar http://click.sourceforge.net

Congrats and kuddos on keeping Velocity alive! After all these years, Velocity is still my favorite template engine; very easy to use but effective. Great for email and code generation and stuff, and Velocity Panel is one of the first components I created for Wicket.

I'm glad to see that Velocity is still alive! I used Velocity about 4-5 years ago: I liked it very much! It is very very productive! I have never understand Velocity have abandoned for a while and why it had not the importance it deserved.

I'm glad to see that Velocity is still alive!
I used Velocity about 4-5 years ago: I liked it very much!
It is very very productive!
I have never understand Velocity have abandoned for a while and why it had not the importance it deserved.

Actually Velocity is a love at first sight affair for me, I have used it first about 4 years ago, and back then I found it close to perfect. The reason why it was stalled was probably, it simply worked for most users and all of the users are pretty happy with it. So there probably was not a big need for major improvements. This is one of the projects which got everything right at the first attempts. Thanks for the velocity guys for the new version.

Velocity is cool and simple, I use it mostly to generate javafiles from a template, good to hear that it is still improved.

Congratulations to velocity developers. I used Velocity 4 years ago for JSP generation. It is incredible simple and powerful at the same time. And for those using Eclipse, the Veloedit plugin is very useful.

I'm really glad to see that velocity is still developed. Besides that is it handy to use for web development it is a great system to create template files for generating source code. I personally have used it to create an eclipse plugin which generates my POJO's, Spring Validators/Custom Editors and DAO's.

Now the question turns back into a Freemarker vs. Velocity debate - which and why?

Joseph, you refer to a "FreeMarker vs. Velocity debate". Certain things are not a subject of debate, really, at least respectable, good-faithed debate. For example, at this stage of history, two moderately well-informed, honest people cannot have a debate about whether the invasion of Iraq was necessary because Saddam was about to have atomic weapons or was behind the 9/11 attacks. Anybody who still believes such things at this point is simply woefully uninformed -- or the other possibility is that they are willfully lying about the matter. In a similar vein, I really question the notion that FreeMarker vs. Velocity is a topic for respectable debate. Now, okay, I'm not an objective source of information this. Anybody can see who I am on the FreeMarker "who we are" page. But still, I think I should outline some salient facts about this supposed "debate". 1. There are extremely high profile open source projects that used Velocity as a component and already had a big investment in it, and then later, decided to transition to using FreeMarker instead. Hibernate is one example. See: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/03#a_story_about_freemarker_and_velocity Webwork, which is now Struts 2, used Velocity as its view component from version 1 onwards and, in May of 2005 (I think) switched to using FreeMarker -- at least by default. I think it is clear that, given that these projects had already been using Velocity for a good while, and had an investment in it, for them to switch implies that FreeMarker was more than just a little bit better. JForum, a very popular discussion forums servlet app began development using Velocity and later switched to FreeMarker. And there are surely other examples.... Now, is there any case of a project, equally high profile or not, having switched in the opposite direction, from FreeMarker to Velocity? I don't think so. 2. Just googling around the various tech blogs out there, you find various people saying that they switched from Velocity to FreeMarker and explaining why, just for example: http://blog.nominet.org.uk/tech/2005/06/29/moving-from-velocity-to-freemarker/ The only example I think I ever saw was a guy named Howard Abrams who switched (temporarily) from FreeMarker to Velocity. Except that he got frustrated by how underpowered Velocity was, and switched back. http://www.howardism.org/thoughts/001511.html And just by casual observation, the FreeMarker user list is full of Velocity refugees; just from some of the discussions that arise, you can see that quite a significant proportion of the people there have used Velocity in the past. I track both lists and it seems to me that the Velocity list is not similarly populated by ex-FreeMarker users. Okay, points 1 and 2 boil down to the seemingly indisputable fact that people switch from Velocity to FreeMarker and there is no similar migration the other way round. What does that tell you? Now, you may say that you are talking about a new version of Velocity, 1.5, that has just been released and maybe that will change things. However, that is quite unlikely. Here is why and it will be a good point 3. 3. The extra features added to Velocity in the latest released version do not bring it up to a level where it is competitive with versions of FreeMarker of 4 or even 5 years ago. In fact, if you look at the blue skies wish list for a (purely vapor) Velocity 2.0, there is nothing in the wish list that has not been part of the stable released version of FreeMarker for the past 4 years or so. Yes, that is how uncompetitive Velocity is currently, and I think what I have outlined above is not really subject to debate. The above 3 points really are just facts. Now, it would be really gratifying for me if someone like you, at theserverside.com simply talked straight about this instead of pretending that there is a legitimate discussion to be had about FreeMarker vs. Velocity. For example, if you wrote a paragraph something like: "Given the fact that the new features in Velocity 1.5, released in 2007 do not bring it up to a level that is competitive with versions of FreeMarker available in stable releases of 2003, I would discourage people from wasting their precious time with Velocity at this point." (Maybe your version of the text would be a bit softer, I grant...) But such straight talk seems very unlikely. There seems to be an agenda of pretending that the emperor is wearing clothes when he is in fact naked, and I guess there are similar mechanisms involved, where people won't point out the real bare truth of the matter (as I have in the above 3 points) for the various similar sociological reasons. So be it. But it does not, in my opinion, serve well your readers, an audience of IT professionals, with limited time to evaluate software tools, to provide anything less than straight talk about this and other matters. At this point, Velocity has not been competitive in its space for years and this latest release is way too little, too late.