[stringtemplate-interest] code-generation to "compile" string templates?

[Eric B]

Hi,

I searched around and could not see if this has been discussed before.  I
was curious if the StringTemplate community has discussed compiling
templates to Java classes as a means to reduce all the reflection used in
resolving extremely dynamic, large templates.  Basically, coders would still
use the StringTemplate language to code up the templates.  At runtime,
though, instead of resolving tokens using reflection, the templates would go
through a one-time process of compiling the template down to bytecode.  The
idea would be that the StringTemplate would not have to use reflection to
resolve templates like the following:

someTemplate(person) ::= <<
<b>$person.address$</b>
>>

At runtime, it instead would compile the template to a class that could do
it without reflection.   Something like the following...

public String someTemplate(Person person){

StringBuilder sb  = new StringBuilder();

sb.append("<b>").append(person.getAddress()).append("</b>");

return sb.toString();

}


The big downside of not using reflection is that it requires the developer
to somehow identify what type of object person is.

Other frameworks/libraries make use of this class-generation technique to
optimize their runtime.  For examples... JSP transparently compiles down to
a Java class and it is that Java class that is used at runtime. Spring uses
CGLIB to optimize their AOP proxies
http://static.springsource.org/spring/docs/1.2.x/reference/aop.html .
 Hibernate makes use of CGLIB...
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html.
   JSP is bit different in that it generates physical Java classes on the
file system.  Spring simply generates the byte-code in memory.

Perhaps the StringTemplate syntax could be enhanced so developers could
develop "strongly-typed" templates?  These types of templates could make use
of a more-optimal code-generation mode.  And the untyped templates would
just be interpreted via reflection as they are today.  Just a thought.

History behind my question...

We brought StringTemplate in to our stack a few years ago while doing some
maintenance work in our UI code.  At this point, we were on Java 1.4.  Prior
to using StringTemplate, much of our HTML was generated in plain Java by
appending on to a big StringBuffer.  We did a bunch of research at the
time... we selected StringTemplate because it would get our string-building
code in to a more maintainable state.  However, after doing this refactor of
our UI code out of Java string-building and in to StringTemplate, there was
a noticeable drop in response time when the system was under load.  I don't
remember the numbers, but using StringTemplate under load was more taxing on
our CPU than the prior approach of building up the strings in Java.  When we
hooked up a profiler and did some analysis on the before/after refactor
behavior, we found the difference was due to the reflection that was used in
resolving our StringTemplates.

As I recently came across this interest list, I thought I'd pose the
question... see if there has been any discussion on the topic.


Thanks,

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20110130/347f0980/attachment.html