Thoughts on agile software development
In previous articles on JUnit 5, various mechanisms were presented with which the JUnit tests could be made clearer. In this article, the ArgumentsAggregator is presented as an additional helpful mechanism.
As soon as the handling of optional values is built into FreshMarker, another interesting feature appears, which could be added with tiny changes. It was implemented in three steps, with the next step only becoming apparent once the previous step had been implemented. The whole thing started with the fact that empty optionals should be processed slightly differently than null values.
Agile software development is characterized, among other things, by the fact that features are developed on demand. This is one of the reasons why some features are not available in FreshMarker or are only added very late. Examples of late additions are the Include- and Import-Directives and the support of the StringBuilder and StringBuffer data types. For the former, the use case was not planned at the start of development and for the latter, support was simply forgotten. Another forgotten data type is the Optional class, which is now finally to be supported.
When updating some libraries that use FreshMarker, I was a bit surprised. The Hamcrest Matcher Generator library was still using Freemarker and also the library has never been published on Maven Central. Two things that should be fixed as soon as possible.
In the second article on the FreshMarker Compiler, we looked at the implementation of a pretty printer for Template instances. This implementation serves as the basis for the FreshMarker Compiler, which generates Java code from a Template instance. Before we tackle the Compiler, we need to look at a few more hurdles and details.
In the first article on static FreshMarker templates, some basic thoughts were put on paper. This article is intended to set a first milestone on the way to supporting much faster templates than before. As a nice side effect of this initial work, a pretty printer for FreshMarker templates will be created.
The template engine FreshMarker occupies a middle position in terms of processing speed for the benchmark displayed on the FreshMarker project page. In line with the concept of a dynamic, expandable engine, a noticeable acceleration of processing is not to be expected. The question therefore arises as to which concept can be thrown overboard in order to significantly increase speed.
The follow-up article on FreshMarker Features took a little longer because there was simply no feature that wanted to manifest itself in a plugin. In the FreshMarker Includes article, the features for activating and deactivating functionalities within FreshMarker were presented. The outlook was given that FreshMarker plugins should also be able to contribute their own features. How this can work is explained in this article.
Nothing is so good that it can’t be reworked. The switch directive in FreshMarker differed from the FreeMarker variant quite early on. FreshMarker’s switch directive does not have a fall-through mechanism. This mechanism is a legacy of the C language family, whose switch statements with break also found their way into the template syntax. Since the end of 2024, FreeMarker now also has a new switch directive. How can this be incorporated into FreshMarker?
In the first article on the Include Directive, I showed how this directive can be implemented in FreshMarker. Although additional content can now be inserted into the template, some additional details are still missing. An important detail is the avoidance of recursive includes. These usually never end well. The following template recursive.fmt shows the simplest form of the problem.