Presentation at JCrete.org

[Remi Forax]

Hello,
I've given an informal talk at JCrete on the template processor / string template,
the content is here
  https://github.com/forax/string-template

Since i've hacked two template processors,
- a JSON processor that creates a tree of JSONObject/JSONArray from a JSON string template and
- a Logger processor that log the string template.

The JSON Processor uses jackson to do the parsing but is able to only parse the string template once, so it's far more efficient than using ObjectMapper.readTree().
The Logger get the current class using a StackWalker, get the logger from the class name (it uses java.util.logging but there is nothing specific to it), checks if the logging level is enabled and log the string template. The whole implementation is loaded as a hidden class so it does not appear in the stacktrace.

I had to rely on the fact that the return value of StringTemplate.fragments() is a constant for a callsite, so an implementation detail, otherwise the performance were terrible. Even with that, for the Logger, I was not able to avoid the creation of a StringTemplate when no logging is needed (something which is easy to do with a lambda). So I don't believe a logger based on a template processor makes sense at least not until StringTemplate.Processor.Linkage becomes non-sealed.

Actually, the main issue in term of performance is the implementation of StringTemplate, which internally uses an array of Objects and and array of longs to store the values. A slimmer implementation could use fields and uses arrays only if the number of values get big (something like 6 objects and 2 longs and reuse at max 2 objects to store the array of Objects and/or the array of longs if there are more objects/primitives values than 6/2.
At least, all the fields should be declared @Stable. The StringTemplate is also a good candidate to be a value type but the inheritance has to be removed for that.
But all these optimisations would be unecessary if StringTemplate.Processor.Linkage was not sealed.

The good news is that all this performance pot holes have nothing to do with the way a template processor is compiled so those things can be improved over time without needed to recompile the code.

cheers,
Rémi

BTW, i've also discovered that the lambda metafactory fails with a VerifyError if the lambda is declared inside a hidden class, I will submit a bug soon once i've a small reproductible code.