Freemarker sucks, dependency on javax.swing, Wouldn’t run on GAE

I would say freemarker sucks.
Yes it does. A template engine has dependency on javax.swing !!
Isnt that surprising?

Today, I was trying to deploy a Stripe/Freemarker hello world app on GAE and I got following.

java.lang.NoClassDefFoundError: javax.swing.tree.TreeNode is a restricted class. Please see the Google App Engine developer's guide for more details.
at freemarker.core.TextBlock.isIgnorable(
at freemarker.core.TemplateElement.postParseCleanup(
at freemarker.core.MixedContent.postParseCleanup(
at freemarker.core.FMParser.Root(
at freemarker.template.Template.(
at freemarker.cache.TemplateCache.loadTemplate(
at freemarker.cache.TemplateCache.getTemplate(
at freemarker.cache.TemplateCache.getTemplate(
at freemarker.template.Configuration.getTemplate(
at freemarker.core.Environment.getTemplateForInclusion(
at freemarker.core.Include.accept(
at freemarker.core.Environment.visit(
at freemarker.core.MixedContent.accept(
at freemarker.core.Environment.visit(
at freemarker.core.Environment.process(
at freemarker.template.Template.process(
at freemarker.ext.servlet.FreemarkerServlet.process(
at freemarker.ext.servlet.FreemarkerServlet.doGet(

Yes, you can not use freemarker on GAE, at least not without hacking it.

I found a patch here, seems that it would solve above exception.

Who knows that it wouldn’t have dependency on more classes. we can just hope for good.

Nope, above solution isn’t going to work all the time.
I had a quick look at the code, I think that the culprit is here.

abstract public class TemplateElement extends TemplateObject implements TreeNode

From the code, it seems that TemplateElement implements TreeNode
Just because it needs contract similar to TreeNode but it does not have any thing to do with swing API. (You already knew that)
Instead of implementing TreeNode, author could have created a new interface which exposes similar contract.

Do we implement any interface which exposes similar contract that we need? Context matters. EJB spec has some interface with methods that a servlet want doesn’t mean it can be implemented by a servlet.

Hope, devs would fix it in next release.
The issue is discussed in mailing list here

At the end, I would like to say, I like freemarker and that’s why I wrote even a hello world stripe application in freemarker.

Update 26/03/2010

Friends at freemarker has released a Freemarker GAE prerelease which can be downloaded here. It should work on GAE.  Any one interested in running freemarker on GAE should try it and report issues if any.

see  freemarker on GAE too.

update 28/04/2010

No, still freemarker-gae-pre2 will not work on GAE, I have tested it on GAE 1.3.2.  You will get one or both of the following exceptions

java.lang.VerifyError: (class: freemarker/ext/jsp/FreeMarkerJspApplicationContext, method: signature: ()V) Incompatible argument to function


java.lang.NoClassDefFoundError: Could not initialize class freemarker.ext.jsp.PageContextFactory

See this thread and this thread . The issue has been reported to GAE team here vote for it.

Waiting for the freemarker or GAE team to come up with explanation/solution.

Leave a comment


  1. Alright, FWIW here’s my opinion… I’m one of primary developers of FreeMarker, even if it wasn’t me who created the dependency.

    Jonathan (who introduced it) thought of it as the easiest way to expose template AST to IDE tooling. Also, note that there’s no standard tree representation API in java.util.* and javax.swing.tree.* is the closest to it; lots of classes and interfaces in it are applicable to any tree data representation, not just ones suitable for a GUI. As Sun mandates the presence of “javax.swing” package in every SE runtime engine that wishes to use the name “Java” it didn’t seem to be a problem.

    Anyway, GAE is not a “Java Runtime Environment, Standard Edition” if it doesn’t have javax.swing.*. I just sent an e-mail to some of my contacts at Sun to clarify the matters, and maybe contact the Google to either stop using the “Java” trademark, or alternatively get their JRE right.

    Google’s decision to not include this package/classes into its App Engine makes that runtime environment into not being a JRE. FreeMarker is developed for running on a JRE.

    GAE has other problems as well. I.e. it interjects its own reflection replacement classes defined in the “” package, that unfortunately run with less privileges than the real “java.lang.reflect” package, so when we use them to, say, reflectively invoke package-private constructors from within the same package – something that works nicely in a real JRE – GAE will throw an exception, since classes in package “” have no access to our package private constructor – the classes in “java.lang.reflect” of course don’t have this limitation as they are subject to no access control.

    I consider all of these to be JRE compliance bugs in the GAE implementation of the Java-like runtime.

    • daringtakers

       /  December 25, 2009

      Thanks Attila,

      You have the point,
      However from design point of view, I wouldn’t agree. Swing is a part of JRE doesn’t mean Its a good idea for a JSP custom tag for Tree to implement interfaces from it. No one would prevent you but a good developer wouldn’t do that. Swing is focused to do some thing else.

      I had a look at the code, I think that its just TemplateElement which has dependency on javax.swing. TemplateElement required to expose contract similar to TreeNode and developer thought its easy to implement TreeNode.

      It would be great If we can avoid this dependency.
      I think that creating a new interface like TreeNode and let TemplateElement implement would solve the problem.

      I would give it a try. Hope it doesn’t have dependency on more classes.
      I would really like to run freemarker on gae.


      • Sure, I agree. In this situation, we’re the small guy and Google is the big guy, so unless Google fixes their JRE, we’ll have to adapt.

        Problem is, we have a policy of not making any changes that break backwards compatibility within minor releases, so it’s not likely we can fix this for the 2.3.x line of FreeMarker. We could eliminate the dependency from 2.4.0 though. The only problem is that we’re progressing quite slowly towards 2.4.0, although the general opinion is that the current SVN HEAD is stable enough for general use. I’ll see to removing the dependency from 2.4.0 code tree, and the resulting SVN HEAD should be usable without trouble then.

      • That would be great, at least if it can be fixed in trunk.
        For now, I will have to drop my idea of using freemarker on GAE.


  2. Also, you’ll likely – unfortunately – run into this problem:

    This is GAE again doing a *nasty* thing: replacing java.lang.reflect.* classes with its own doppelgangers, Since we’re using reflection to access non-public members (but still legal access – i.e. class accessing its own private member, or class accecssing a package-private member within the same package), Google’s interference into the reflection will break it, as its own reflection replacement classes don’t have the same access privileges as java.lang.reflect.* classes do.

    That’s why I’m saying GAE Java support should not be allowed to use the name “Java” – it’s not just javax.swing.*, it’s also fundamental breaking of otherwise legal reflective access of non-public members.

    • daringtakers

       /  December 25, 2009

      Agree, there seems to be many core API that wouldn’t work on GAE. Unfortunately we can’t do any thing. As you said “we’re the small guy and Google is the big guy”

  3. I would like to introduce you to Rythm template engine. There is a full feature set demo running on GAE: Here is some facts:

    * Razor like syntax, very friendly to Java programmer
    * Null safe expression: @foo?.bar?.zee()
    * Compile to Java byte code, 2 to 3 times faster than velocity
    * Support template layout
    * Very powerful template reusing mechanism, tags/macros/includes
    * Built in cache support
    * Sophisticated encoding support

    Code is hosted at

  4. Just an interesting note. I am also having this problem but discovered something. Consider this markup.




    You will get the error about the Tree dependency.

    But add a little text in between ${summary} and ${agent}, the problem goes away.


    Add some text here


    Just an observation.

  5. I have just hit this problem; it’s a shame I cannot use Freemarker on GAE, but I agree with Attila: this is Google fault, no question.
    Freemarker is a very good library, it is always my first choice when it comes to templating in Java (unless Groovy is allowed in the project of course!)

  1. Freemarker sucks, dependency on javax.swing, Wouldn’t run on GAE

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: