The Jamon Templating Engine

A Conversation with Ian Roberston

by Bill Venners
January 28, 2009

Summary
In this interview, Ian Robertson, co-maintainer of the Jamon text template engine, discusses why he feels static typing is useful in a template engine.

Bill Venners: Can you given an overview of Jamon?

Ian Robertson: Jamon is a templating engine. Among the templating engines most people are aware of, Jamon is probably most similar to Velocity. But there are a few big differences. The most significant difference is that it has static typing. A Jamon template will declare the arguments it's taking in, and the types of those arguments. Then all code in it is actually converted into Java code, and is type checked by the compiler. It also has a few additional features that Velocity doesn't have, including the ability for a template to pass a subtemplate as an argument to another template, which is useful for certain looping constructs.

Bill Venners: Most templating engines that I'm aware of are not statically typed. JSP is statically typed, but Velocity, Freemarker, StringTemplate are not. They don't provide compile-time type or name checking of any kind. What are the advantages and disadvantages of using a statically typed templating system?

Ian Robertson: I think the main advantage is the same advantage of having a statically typed language, You described JSP as statically typed, but even JSP I would consider in some ways dynamically typed in the sense that arguments are passed in through the request context. You're pulling them out by name, and then you're hoping they are the right type. And it makes refactoring extremely difficult. If you decide you want to change some of your model objects, which are being referenced in the view, it's very difficult to figure out how that's going to impact the view. We have had to make refactorings at Overstock, where we use Jamon for our website, fairly significant refactorings. And we were able to do it with a high degree of confidence, because anything that we get wrong, we're going to know before we've even successfully compiled. And I think that's probably the single biggest reason.

It also provides, as any static typing system does, a better documentation. You can tell looking at a template, not only what data is coming in by the name the data is given as a variable, but you can look at the type and see ah this is actually a list of product recommendations. And I can look at that bean and understand what it does. I can really know what's going on without having to guess.

Bill Venners: So what is the advantage of FreeMarker and Velocity's approach? What are they getting that you don't get if you take a statically typed approach like Jamon?

Ian Robertson: There is a loose coupling that's involved when you don't have the static typing. And I think that is probably at least a large perceived advantage of these other templating languages. But in my opinion, this is an image of loose coupling, but it's not true loose coupling. It's true that you can change the type on one side, and everything will still work--until you try to run it. And then everything falls apart, with a NullPointerException if an expected parameter wasn't passed, or a ClassCastException if the parameter had the wrong type. I've talked with some people who initially questioned why Jamon didn't have this loose coupling model, which makes it very easy to work with a lot of frameworks, for example, Spring MVC. But when you dig down, you find that the loose coupling is a facade.

Resources

You can download Jamon from here:
http://www.jamon.org/

Talk back!

Have an opinion? Readers have already posted 2 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima, Inc., which publishes the Artima Developer website at www.artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform’s architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community’s ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community’s initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers.