Chunk: yet another Java Template EngineJan 01 2011 | 14:24:17 | 5 Comments

Simple, powerful templates for Java

Simple, powerful templates for Java

Q: Does the Java community really need yet another templating engine?

A: Not really, but back when I started Chunk, there wasn’t anything else out there like it. Now that it has matured, I am releasing it into the wild, and if somebody finds it useful, great!

Click below for an introduction to better code/layout separation:


  • Macros, Includes and Conditional Includes.
  • Flexible null-handling; template designer may specify default tag values.
  • Library of powerful predefined in-tag filters, including regex (regular expressions), sprintf.
  • Expose a subset of obj methods to template with a single line of code.
  • Define multiple snippets per template file.
  • Support for theme layers with inheritance.
  • Highly optimized codebase.
  • Hooks for extending.
  • Localization framework.
  • Eclipse Template Editor plugin available with syntax highlighting & more.

Visit the Chunk project home on Google Code to download the Chunk Templates jar and get started.

I don’t know if Chunk is better than Velocity, I don’t know if Chunk is better than FreeMarker, but I’ve been using it for years and it’s gotten pretty cool.

Hackers are encouraged to contribute enhancements back to the community.  Google is hosting the code on its SVN server so it’s easy to check out a copy of the source and make whatever improvements you need.

5 Responses to “Chunk: yet another Java Template Engine”

  1. can a POJO be used as the model source like in mustache? or must one use a DataCapsule around a POJO.

  2. For simple cases, POJO data can be pulled out and mapped in a series of chunk.set(…) calls. You pick and choose what to expose to the template, so this offers the most control. If you can serialize the object into anything that implements Map, then you can get away with a single chunk.set(“x”, myMap) call and use {$x.attr_name} tags in the template.

    Otherwise, yes, you can write a wrapper object that implements DataCapsule and wraps the pojo in a decorator pattern. This is a feature, not an omission — the idea is, you wouldn’t want the template to be able to execute arbitrary code in your model classes, and even DataCapsule has an implicit contract to only offer access to getters with no side effects.

  3. has a different philosophy whereby everything in a POJO is exposed, rendering them simple to use. Security is left to the POJO implementer who retains full control.

    Obviating any wrapper requirement puts less burden on implementers.

    One man’s feature is another man’s limitation.

  4. I took a look at Sam Pullara’s implementation of mustache for Java — he’s not exposing *everything* in the POJO, he’s just exposing the public member variables. I don’t typically see Java models implemented this way (it’s strongly discouraged by The Man but of course there’s always room for healthy debate), so I never thought to handle data objects quite this way but I’ll definitely consider it for a near-future release.

    Thanks for the feedback!

  5. I should have stated… “every public thing.”

    Note that JavaBean getProperty notation is also accepted.

    This makes it very simple to reuse existing legacy objects by directly exposing them in a template that otherwise would require implementing some boilerplate wrapper.

    Adding this functionality to the other powerful chunk features like filtering would make chunk a really compelling solution.

    Thanks for your consideration.

Leave a Reply