FreeMarker Blog

FreeMarker is on Twitter

2010-02-16T11:07:00.001+01:00

Did you know you can follow FreeMarker project on Twitter?

FreeMarker on Google App Engine

2010-02-14T11:39:00.006+01:00

We had several reports of issues in the past with use of FreeMarker on Google App Engine (GAE).

Analysis of these problems confirmed that runtime named "Java" in GAE is not, in fact, a Java-compliant runtime even though it's advertised as such, and looks like one at first sight. It doesn't provide access to some mandatory Java packages, and its reflection implementation has bugs; both of which issues affect FreeMarker.

We wish to stress that FreeMarker is being used in countless Java runtimes, many of them enterprise runtimes with strict security lockdowns, and it works in all of them, as long as these runtimes are conforming Java Runtime Environments. It is our belief that GAE is, unfortunately, non-conforming. Update: I have now reported the reflection bug in the GAE issue tracker.

This unfortunately doesn't help our users who would love to use FreeMarker on GAE. We can not quickly patch FreeMarker as some of the required workarounds would break backwards compatibility within the existing 2.3.x series, which is against our release policy; backwards compatible changes are only allowed when we increment first or second version numbers, that is, from current perspective, either in 2.4 or 3.0.

For this reason, I spent some of my weekend on this particular yak shaving, and have created a new version of FreeMarker's 2.3.16 JAR file that should run on GAE. I'm saying "should" because I don't use GAE myself, so it's up to you, the GAE users to verify it.

If you want to, please go to our project file releases, and grab "freemarker-gae-pre1.jar" from freemarker/2.3.16 directory. The file is labelled "pre1" as it's considered a prerelease; all you people who wish to use FreeMarker on GAE, please start using it and hammer at it, and report back any problems you can find. That said, I sincerely hope there will be none. The changes themselves are fairly light: I removed the dependency on Swing from AST classes, and worked around GAE's reflection security bugs. (If you see a different named file, it means we've updated it since, and please grab that more recent one.)

Update: There is now indeed a "freemarker-gae-pre3.jar"

This doesn't replace our longer term effort of having default FreeMarker be able to run under GAE, but is intended to help our users with an instant solution. There are no downsides to using this version instead of the official 2.3.16 release of FreeMarker, except for the backwards-incompatible change where the TemplateElement class no longer implements Swing TreeNode, but that incompatibility is probably exactly what you want under GAE. All other changes are under the hood - we had to expose few previously package-private implementation classes as being public to work around GAE's reflection security bugs. Since these classes are not documented in FreeMarker official JavaDoc anyway, they don't form the public API, so you shouldn't be using them even when you see them.

FreeMarker 2.3.16 released

2009-12-08T14:13:00.002+01:00

FreeMarker 2.3.16 is out! Download it from here.

This is mainly a bugfix release; you can see the full changelog for details.

FreeMarker 2.3.12 released

2008-02-04T08:41:00.000+01:00

FreeMarker 2.3.12 is out! Download it from here.

We fixed one really ugly (and really stupid to make) bug that made the JSP 2.0 SimpleTag support introduced in 2.3.11 immediately unusable (ouch). Everything gets better at second attempt, I guess, so it works now; with my apologies to anyone bitten by it.

FreeMarker's praised error reporting got even (a bit) better: parse-time exception messages now display the name of the template in addition to line and column number (I too can't believe we didn't have this earlier).

Variable argument methods (introduced with Java 5) on Java objects can now be properly invoked (in case of overloaded methods, observing the same rules for method resolution that the Java language itself uses).

Finally, Java 5 enum constants are now identified by their name, not their toString() representation (which can be overridden in a subclass). They still print their toString() representation, of course.

FreeMarker 2.3.11 released

2007-12-05T09:17:00.000+01:00

We're pleased to announce that FreeMarker 2.3.11 is now released. This release contains several important bugfixes, performance improvements (both speed and memory), as well as some major feature improvements. It is almost completely backwards compatible with any other 2.3.x version and as such can be used as a drop-in replacement for them. (The only non-backwards compatible change is that ?c built-in formats numbers differently than it did earlier, but that is actually a bug fix).

Download it from SourceForge

You can look at the full list of changes, but I'll summarize it here by topic:

New features

We now have much better JSP 2.0 and JSP 2.1 compliance. Most notably, JSP tags implementing SimpleTag interface will now work.

We have better Rhino compliance as well: Rhino objects can be used in templates as scalars, numbers, and booleans, following the JavaScript conversion semantics for these types.

We created a new interface, TemplateDirectiveModel that should make writing custom directives in Java much easier than with the previous only choice, TemplateTransformModel.

And then there's the small things, i.e. FileTemplateLoader can now load templates through symlinks pointing out of its root directory (it is disabled by default however).

Performance improvements

We eliminated a bunch of repeated instanceof tests in BeansWrapper whenever a new object was wrapped. They're now performed once per class instead of once per object. Also, the FreeMarker wrapper object created by BeansWrapper when wrapping a POJO now does not create an internal HashMap automatically, but only when really needed (and it is not needed often). Thus, we eliminated one HashMap per wrapped object in lots of use cases, noticeably reducing the runtime memory footprint.

Bug fixes

As mentioned, ?c built-in now prints numbers in the expected format always. Also, there is a serious file handle leak when loading resources from JAR files from local filesystem in Sun JVMs, and we now have a workaround for it. FreeMarker will now correctly find JRE-bundled Xalan when run on Java 5 and Java 6. Also, we corrected the lookup of JSP taglib JAR files to be fully compliant with the JSP specification. And there are some more I won't go into right now - see the full changelog page linked above.

Velocity or FreeMarker: Looking at 5 Years of Practical Experience

2007-12-02T20:37:00.002+01:00

This month's Javaworld contains an article by Jeroen Van Bergen entitled "Velocity or FreeMarker". While it is, of course, nice to get such good publicity for our project, I have certain misgivings about the article and I feel it is necessary to make certain points about it. I have chosen to do so on this blog because this entry will provide a basic link to refer people to in the future, any time we feel these points need to be made.

Here is my central concern about the aforementioned article: typical readers, not very familiar with the template space, will come away with the idea that Velocity and FreeMarker are broadly comparable in functionality, and that it does not matter very much which one you choose. However, they would be extremely mistaken. There is now five years of practical experience that shows that, in the general case, Velocity is not a sufficiently capable tool for professional use. This is why so many projects -- among them some of the most visible projects in the java world, things like Hibernate, Webwork/Struts 2, and Netbeans -- used Velocity at some earlier stage, but have since migrated to FreeMarker.

Quite amazingly, Mr. Van Bergen's article makes no mention of any of this. So let me start by filling in some of this background.

Max's story about FreeMarker and Velocity

One of the better known cases of a project switching from Velocity to FreeMarker is Hibernate tools. In early 2006, the lead developer, Max Andersen, wrote a blog entry about this that generated some buzz. While Max outlined various issues he had with Velocity, his biggest problem, the central message, was that he simply could not get Velocity to provide useful error messages. If he misspelt a variable somewhere in a template, the default behavior was just to keep going as if nothing happened. Even if he configured Velocity to throw an exception at this point, he had no information about the line number or even the file in which the error occurred.

Now, to be fair, the most recent version of Velocity has some improvements on this front. However, Velocity is still quite weak in error reporting compared to FreeMarker, and real practical experience with both tools shows that the lack of good error messages can be a huge drag on developer productivity.

Error messages were also one of the two stated reasons that the Webwork project, in early 2005, switched from using Velocity by default to FreeMarker. The other was FreeMarker's support for JSP taglibs. Note that Webwork later was donated to the Apache Software Foundation and was renamed "Struts 2". At around this time, Matthew Porter wrote a blog entry describing his switch from Velocity to FreeMarker for all his development.

Now, meanwhile, other people undertook the same migration but for other reasons. Consider Matt Ward's blog entry from mid-2005. One of Matt's main problems with Velocity was that Velocity simply did not address the whole issue of outputting numbers, dates, and currencies, for different audiences, despite the fact that the information to do this is embedded in the core java libraries. Another issue for Matt was Velocity's lack of robust support for macro libraries. FreeMarker supports the notion of namespaces so that different sets of macros can define variables without any fear of them clobbering one another.

More recently, it has come to our attention that Netbeans 6 leverages FreeMarker for templating functionality. (Previous versions were using Velocity.) I have not seen any public explanation of their reasons, but I infer that they were running into various limitations of Velocity, and were looking for a better tool and opted to migrate towards FreeMarker. Consider this blog entry outlining how to adapt to the change to FreeMarker.

What about changes in the other direction?

Now, so far, I have provided examples of people switching from Velocity to Freemarker, but none of anybody going in the opposite direction. Well, feel free to look for examples of this. Google is your friend.

I can only find one example. In this blog entry, Howard Abrams, a long-time FreeMarker user, describes his experience switching to Velocity. Except that he finds Velocity to be too limited, and switches back to FreeMarker!

Final Points

In the foregoing, I highlighted examples of 5 years of practical experience that the java development community has had with Velocity and FreeMarker. Jeroen Van Bergen's article simply omits all of this. While that is surely the central problem, I should still point out other issues with the comparison carried out in the article.

For example, on the last page is a feature checklist chart, showing features that FreeMarker has and Velocity has. FreeMarker allows iteration, Velocity allows iterations, FreeMarker has macros, Velocity has macros. And so on. The chart is outrageously misleading, because it suggests that the two tools are comparable functionally. But that is simply because it omits all the features that FreeMarker has that Velocity lacks!

A more complete list would contain things like:

Support for transparent i18n with numbers and dates shown according to the relevant locale: FreeMarker, yes. Velocity, no.
Support for JSP taglibs: FreeMarker, yes. Velocity, no.
Support for Jython and Rhino: FreeMarker, yes. Velocity, no.
Special tags for stripping of extraneous whitespace: FreeMarker, yes. Velocity, no.
Support for auto-escaping interpolations on blocks of text (converting problematic characters to HTML entities, for example): FreeMarker, yes. Velocity, no.

Also, just consider the statement that FreeMarker has macros and Velocity has macros, with no further elaboration. It is actually true, as far as that goes, but it is certainly quite misleading. Now, it is true that in paragraph below that feature checklist chart, the author does mention that FreeMarker's macro system has some additional capabilities. However, the basic impression given from the way the information is presented is that the difference is at most marginal. Surely, a more complete feature checklist of the tools' respective macro capabilities is called for and that would be something like:

Support for importing a set of macros (macro library) in a separate namespace to avoid variable naming clashes: FreeMarker, yes, Velocity, no.
Support for macros with an associated template block: FreeMarker, yes, Velocity, no.
Support for optional and default parameters in macro calls: FreeMarker, yes. Velocity, no.
Output of the macro call stack when an error is hit: FreeMarker, yes. Velocity, no.

Right below this, Mr. Van Bergen mentions Anakia, which is an add-on to Velocity for processing XML. He neglects to mention that FreeMarker provides similar XML processing functionality (though the implementation is much more complete, since it supports XML namespaces, for example) as part of its core feature set. Declarative XML processing is supported in FreeMarker via the #visit and #recurse directives, which are core directives in the FreeMarker language. One would infer from what the article says that XML processing is a point in favor of Velocity, when, really, quite the opposite is the case. The XML processing functionality available for Velocity is add-ons like Anakia and DVSL that are basically abandonware, where the XML processing support in FreeMarker is a core part of the product, and is clearly supported.

Still, the central problem with this article and the comparison it undertakes is that it ignores this huge body of evidence from real-world experience that all points to a very clear conclusion: quite frequently, people switch to FreeMarker after hitting Velocity's limitations. In Max Andersen's case, it was the poor to nonexistent error reporting, where for other people, it is Velocity's half-baked, rather buggy implementation of macros. And then, in other cases, the deal breaker is Velocity's lack of transparent support for internationalization. But regardless of the reasons in the specific case, it is quite clear that there has been a large migration from Velocity to FreeMarker and virtually no movement in the opposite direction. In the foregoing, I mentioned cases that are highly visible like Netbeans or Hibernate. We can only speculate about how many projects are out there, most of them not visible at all, because they are in a company's closed codebase, that have ended up undertaking a similar migration. In any of these cases, the people involved could have saved themselves a lot of time and effort by opting for FreeMarker in the first place, rather than starting with Velocity, discovering its limitations, and then having to migrate. So, it serves the readers of a publication like Javaworld rather poorly to have articles that foster the misconception that FreeMarker and Velocity are broadly comparable in functionality. They are not. There is an overwhelming body of evidence from real-world praxis that shows this quite clearly.

New features in the next release

2007-08-19T16:03:00.000+02:00

We're nearing the release of FreeMarker 2.3.11. You can try out the latest freemarker.jar build right now if you can allow yourself to run experimental code and provide us with feedback. Just download it and drop it in place of your existing FreeMarker 2.3.x JAR file. Here's a nonexhaustive list of new and improved features:

Probably the biggest news is that we support JSP 2.0 SimpleTag now. More precisely, you can now use JSP custom tags that implement the SimpleTag interface within FreeMarker.

BeansWrapper's wrapping performance has been significantly improved. Previously, we did a bunch of instanceof checks on each object to figure out how to wrap it. Now, we perform only one lookup per class (instead of per object!), and subsequently quickly dispatch to wrapping code based on the class of the object. ^*

Memory footprint of object wrappers using BeansWrapper has been reduced; we no longer create a per-object member map for each wrapper until you invoke a method through the wrapper. Property accesses don't count, so you get a reduced memory footprint if you use ${foo.prop} but you don't get it for ${foo.getProp()}. As in majority of cases, people tend to use properties, this has the potential to significantly reduce the load on GC.

When using Rhino JavaScript objects as data models in template, they are recognized as boolean, number, and string values following the JavaScript conversion semantics to these types.

^* People who subclass BeansWrapper and override getInstance(Object, ModelFactory) will need to instead override the new getModelFactory(Class) method to take advantage of performance improvement. Overriding the old method still works (we promise to keep backwards compatibility within a major release), but doesn't realize the performance benefit.

FreeMarker sketchbook

2007-07-09T11:58:00.000+02:00

FreeMarker sketchbook is a quite polished (especially for a "0.1" release!) online playground for exploring FreeMarker. It's a JLNP application, and it launches into a Swing application with a tabbed window with tabs containg the full FreeMarker manual, a sample data model, an editor for the template, a HTML viewer for the output, and a HTML source viewer for the output.

Neat!

..the programmer who is in agony with business...

2007-06-25T14:03:00.000+02:00

A bunch of years ago, I was interested in the whole topic of machine translation and had a look at it. A lot of people were making various claims about the technology. I eventually came to the conclusion that machine translation, to put it mildly, did not work very well. In fact, I believed at the time that businesses and government agencies investing in this tech were, at least at that point in history, throwing away their money.

It definitely did not seem that human translators' jobs were under very much threat at all -- certainly not in the short term, almost certainly not in the mid-term. (Maybe in the long run, but in the long run, we're all dead...)

I was kind of wondering, what with all the cycles of Moore's law and so on, whether there was some brute force method that made use of all that, and produced better results than back then. And, you know, some improvements must have been made, what with some very smart people working on what is surely one of the biggest AI problems of them all, natural language processing.

Anyway, what does this have to do with FreeMarker? Well, about a year ago, I wrote an article in this very blog about the designer-developer division of labor. This must have made some impression on at least somebody. I somehow noticed recently that somebody had gone through the bother of translating it (not quite all of it, I don't think, he probably got tired) into Korean and putting it here.

Quite flattering that somebody would translate my rambling into Korean...

I'd actually noticed this a while ago. Today, it occurred ot me to run the translation through translate.google.com to put it back in English. Just out of curiosity. This is what you get. It starts off something like:

Relates with the template engine and the general concept which becomes known two basic groups (the programmer who is in agony [cik] with business and web site is beautiful the designer who pursues) effort between the low of the union is one.

And there are later gems, such as:

The graphic designer American part of head of a family web site it is in agony, ...

That program thinks people are in a lot of agony, doesn't it?

Well, there it is. Of course, I anticipate that Daniel Dekany will say that this retranslation is an improvement over my original text. After all, there is no accounting for tastes.

2.3.11 roadmap - focusing on JSP improvements

2007-04-22T11:37:00.000+02:00

For the FreeMarker's next release (2.3.11) I will focus on improving the JSP tag library support. We have one bug reported for FreeMarker not complying completely to JSP specification for the lookup order of tag library JAR files as well as one feature request for supporting JSP 2.0 SimpleTags. Both of these are rather nontrivial to implement, so they'll take some time. (Also, this is not to say these will be the only changes for 2.3.11.)

Of course, all of these improvements also go into the (separately maintained) codebase for our next major release, 2.4.0.

FreeMarker 2.3.10 is released

2007-04-22T11:26:00.000+02:00

We're pleased to announce that FreeMarker 2.3.10 is now released. This release contains several important bugfixes and minor feature improvements. It is completely backwards compatible with any other 2.3.x version and as such can be used as a drop-in replacement for them.

Download from SourceForge

Full list of changes

Apologies

2007-01-26T11:50:00.000+01:00

To folks who get this blog on RSS feed -- sorry for the last two posts (they have been deleted now). They don't have anything to do with FreeMarker, and were meant to go to my personal blog, and ended up by my mistake on this blog...

FreeMarker 2.3.9 released

2007-01-24T09:39:00.000+01:00

FreeMarker 2.3.9 is now available.

You can download it directly from here

This release adds support for accessing Java 5 enums and public fields of classes in templates, as well one bugfix in RhinoWrapper.

Detailed changes on the Java side:

BeansWrapper can now expose public fields of objects to the template if you call the setExposeFields(true) on it.

Support for JDK 1.5 enums in BeansWrapper and DefaultObjectWrapper. By calling the getEnumModels() method, you can retrieve a hash model that is keyed by class names and allows access to enumerated values. I.e. if you bind this hash model under name enums in the data model, you can write expressions like enums["java.math.RoundingMode"].UP in the template. The enum values can be used as scalars and support equality and inequality comparisons.

freemarker.ext.rhino.RhinoWrapper now correctly translates Rhino Undefined instance, UniqueTag.NOT_FOUND, and UniqueTag.NULL to FreeMarker undefined value.

Please note that currently only http://fremarker.sourceforge.net is up-to-date regarding 2.3.9. http://www.freemarker.org will be updated as soon as I get access credentials to it.

2.3.9 coming soon

2006-11-29T09:52:00.000+01:00

We're about to release the version 2.3.9 of FreeMarker soon. It'll be a release that adds few minor features to 2.3.8, most notably support for accessing public fields of classes as well as JDK 5.0 enumerations from templates. Plus there are few miscellaneous bugfixes in less used areas of the codem, namely Rhino support and the remote debugger. The reason we're delaying the release a bit is to get some feedback on the remote debugger fixes first - there is someone out there trying to write an Eclipse IDE plugin on top of that.

The Designer/Developer Division of Labor Revisited (Alternative Title: The Three-Way Manifesto)

2006-07-12T17:54:00.000+02:00

The conventional wisdom floating around about template engines is that they facilitate a division of labor between two basic groups: programmers, who are concerned with business logic, and designers, people who are more concerned with the aesthetics of a website.

I reckon that this whole argument has become so commonplace as to have become a kind of overused cliché. Of course, if this is the case, we are as guilty as anybody. Certainly, we dutifully expound this idea in the introductory pages of the FreeMarker documentation. In fact, the organization of our documentation, where there is a separate standalone part that is for designers and another part specifically for programmers, reflects the 2-way division of labor that is being promoted.

Of course, the whole thing has a certain conceptual beauty to it. After all, there are two sexes (approximately, anyway) and most people are at least vaguely aware of the brain mapping research regarding the two hemispheres of the brain and their respective specialties. So, in this vein, that there are two basic kinds of people involved in web development just fits in with all of this in a very conceptually neat kind of way.

Now, I don't mean to say that this is invalid. Of course, different people are good at different things. Having hard-core programmers work on designing web pages is usually disastrous. It is even more obvious that you cannot expect people who are good at graphical design to do much programming. The idea I want to develop here is that the 2-way division of labor is, in the general case, an oversimplification, and it may be better to think of things in terms of 3 basic roles: application programmer, graphical designer, and website integrator.

I guess it is clear enough that application programmers write code in a language like Java. Broadly speaking, they are concerned with defining the back-end data structures and the algorithms that operate on that data. As regards their contact with a templating system, application programmers would, ideally, be able to hand off data to the front end of a system and suppose that it will be displayed appropriately. Graphical designers are mostly concerned with the aesthetics of a website, so they spend a lot of time in programs like Freehand and Illustrator and so on. (As a side note, I, a professional programer, have never opened either of those programs and don't even know what they look like on-screen.)

The problem that I see with dividing the work of web development into the above two categories is that it seems to leave a very big gray area in the middle, where it is not so clear whose territory it is. Now, of course, once things reach a certain level of complexity, one cannot usually fit everything into neat unambiguous categories. So, this is normal, up to a point. But this is really a very very large gray zone. It definitely seems to me that, at this stage of history, to master all of the various web-related standards such as javascript with dynamic HTML, and cascading style sheets, along with technologies such as FreeMarker, is a sufficiently large undertaking that it comprises a respectable professional specialty or subspecialty at least. Insofar as things like Oracle database admin or unix sysadmin are also recognized job categories, there is no reason that this should not be. And I think that, increasingly, it is.

So, I have been wondering whether thinking about web development in terms of a 3-way division of labor will often be more useful than the two-way designer/developer dichotomy. In terms of FreeMarker, it allows us to think more clearly about who uses what features, and the basic real-world problem space that motivates them. (However, I think the 3-way paradigm could also be useful to people who are thinking about developing other, related tools in the space, such as web application frameworks.)

Now, in the 2-way division of labor, how does one go about working up a website with dynamic pages? Well, one way -- the approach I myself have typically used -- is that the programmer types work up some basic web app with very basic, ugly page templates and the templates are handed off to the designers who beautify them. The other way would be for the non-programmers (designers along with the marketing types) to work up the web pages with dummy forms and dummy data and then hand off these pretty but non-functional pages to the developers to templatize them and render them functional.

So, basically, either you start with functional, ugly templates and make them visually appealing, or you start with pretty, non-functional pages and templatize them, rendering them functional. You have these two basic approaches. Which is better? My sense of things is that this would be a sterile debate, akin to discussing whether it is to crack open a boiled egg on the small or the large end. The same result can be achieved effectively either way.

Actually, my sense of things is that if that was all there was to it, the 2-way division of labor would be a reasonable paradigm. The problem with the above scenarios is that they really relate to the initial step of developing a prototype. They don't model the multiple iterations and shifting requirements and (sometime chaos and confusion) that occur over the entire life cycle of the project. It also begs the question of how you reuse presentational elements when you start a new, related project. Surely, you don't want to start from zero each time when so much of the same problems recur over and over... And, in general, there is a danger in thinking that an approach that yields quick results for developing a prototype is going to be the best approach for long-term development; it's not necessarily so.

For starters, in web-based development, a huge amount of painstaking work goes into making sure that a site is usable in different browsers, at different resolutions, and so on. Also, there is a whole set of problems involved with creating branded and localized versions of a product or service. Moreover, I am sure that it is fairly common that new requirements in this regard may be introduced at a fairly late stage of the development cycle.

Now, on the one hand, these are problems that are hardly trivial in nature. But, on the other hand, the same basic problems keep recurring (though with minor variations perhaps). In any case, once you've invested a lot of time into figuring out how to get some nice table-based presentation to show up well on different browsers and at different resolutions, it is natural to want to encapsulate your solution so that it can be reused elsewhere, especially when you anticipate that people will at some point want a Spanish language version of the site, say, or just to do something very similar in another context (though slighty different.) Of course, the basic antipattern of copy-paste-modify is always available, but, just as in hard-core programming, there are huge gains to be had long-term by avoiding this. Once you've solved a problem once, you should want to encapsulate the solution and reuse it. This is true with regards code in java and other programming languages, but there is no reason or the same thing not to apply to HTML.

The problem I see is that, while graphical designers will be good at solving problems related to presenting data, they are not, by training or inclination, well suited towards generalizing their solutions in a reusable way. But I also do not think that the hard-core java programmers are typically very inclined to invest their time in this. Well, if it so happens that we are talking about a common core kind of problem and neither designers nor programmers are typically going to address it, then finally, it seems that there is a need to think in terms of a third kind of category -- a team memer who I shall refer to as a "website integrator", One aspect of this person's work is that they are looking at how to encapsulate presentational elements in a reusable way.

Let's consider this scenario: a corporation of a certain size has a very large web presence. This web presence developed in a chaotic way with different subdivisions investing in disparate web-based projects. Eventually, this entity wants to unify all those efforts and present a common corporate look-and-feel across the board. Ultimately, it seems to me that this would largely amount to having a set of common reusable building blocks; that would bring the twin benefit of avoiding superfluous repeated labor, and also that, reusing these building blocks would naturally tend to yield a certain consistency of look-and-feel across the various subsites that make up that entity's overall web presence.

Probably most readers realize at this point that when I talk about corporations investing in reusable building blocks, I am thinking in terms of FreeMarker macro libraries. Of course I am. However, the comments are still of a general nature, where I am thinking that a templating technology -- FreeMarker or some alternative -- must have powerful enough macro capabilities to support building reusable components.

This leads me to a basic itch I want to scratch. There is a kind of rhetoric about how a template language should be extremely simple. For example, simplicity (i.e. a lack of certain features) is frequently touted as a great feature of Jakarta Velocity. Now, I think that many perceptive people suspect that this is largely an attempt to justify the lack of ongoing development in that project. Certain needed features have never been added, and the simplicity rhetoric can be conveniently trotted out when people bring this up. However, whether the simplicity argument is made in entirely good faith or not, it is fallacious. But here is an interesting point: the fallacy is not readily obvious when you use the 2-way division of labor; in fact, it may largely be a result of taking that paradigm too seriously. The argument is basically that people who work on page templates are graphical designers, so the templates have to be dead simple... However, thinking in terms of the proposed 3-way division of labor, the underlying fallacy is immediately laid bare. Once you think that way, you see that the third category of team member, the website integrator, also works extensively with templates, and a person in that role really must have a template language with macro capabilities sufficiently powerful to build libraries of reusable components. And I think this corresponds to the intuition of people who are experienced in web-based development: in the general case, going beyond little toy projects, yes, you do need these more powerful macro capabilities.

(The other way to deconstruct the fallacy, by the way, is to realize that it is based on extending a solid, sound idea in an unsound way. It is surely bad practice to put application level logic in your page template -- an extreme example would be having your template make direct SQL queries against a database. That is a sound principle, so far so good. However, this gets extended in an unsound way to mean that all programmatic logic, even that which pertains to presentation itself, such as reusing presentational elements should be avoided in page templates. And I think that is fallacious in a fairly obvious kind of way. But again, the 3-way division lays bare the fallacy where the 2-way paradigm does not.)

As a closing note, I am well aware that in very many projects of a certain scale, the programmer and the page designer are frequently one and the same. Thus, many readers could well be thinking: I'm not even managing to have the 2-way division of labor going, and here you are talking about a 3-way division!!!

Well, fair enough, but I don't think it is exactly the point that you must have such a division of labor. I am not saying that. Of course, in real life, even if it is hardly optimal, people will have to wear multiple hats and be jacks of all trades. However, even in such cases, maintaining a clear architectural separation between model and view and the separation of roles it implies is a useful organizational principle. So I would say that, similarly, in the 3-way paradigm, the java programmer, the designer, and the website integrator might all be the same person, or it might be that the programmer and website integrator are the same person, but the graphical designer is somebody different. I would say that, even if you don't manage to have the full division of labor because people have to wear more than one hat, it is still useful conceptually. In fact, currently I am tending towards the idea that the 3-way division of labor is essential for thinking sensibly about what tools like FreeMarker are about, and probably also web application frameworks. It seems to me that the 2-way division has lived past its usefulness and concentrating on it will lead to erroneous thinking.

Musings about Competition, Ego, Open Source and specifically, the Webwork/Struts Merger

2006-03-05T18:04:00.000+01:00

Recently I read an interesting article in the New York Times about upper middle class parents from Asian countries who moved to the U.S. specifically so that their children could avoid the rigors of the highly competitive education system in their home countries. There is the feeling that that kind of pressure cooker system robs children of their childhood and teen years. They want their kids to get an education of course, but they also want them to have a normal childhood.

The article had one ironic aspect, though. The Asians in the article were settling in areas that were known to have schools that were much more academically demanding than average. (These, by the way, were typically New York neighborhoods that historically, have been predominantly Jewish but now are becoming increasingly Asian.) The schools in these areas are much more competitive and demanding academically than the norm in the United States, but I infer that they are still a romp in the park compared to the schools these kids would attend in Japan, Korea, or Taiwan, say.

Just how extreme the situation can be is, apparently, no joke. I remember reading elsewhere that the teen/youth suicide rate in Japan was alarmingly high. This is widely believed to be a side effect of subjecting young people to those kinds of extreme competitive pressures.

There are liberal or progressive theories of educational reform that decry the role of competition; alternative schools have been set up that abolish tests and grades. Certainly, if an educational system could abolish competition for grades and be based instead on instilling in students a genuine love of learning for its own sake, this would be a wonderful thing.

The problem is: how do you foster excellence in a non-competitive environment? If nobody set up competitions like the Olympic Games and so on, would anybody have ever bothered to run a mile in less than 4 minutes -- if they were running for the pure joy of running? Maybe that's not a great example, because I don't know how much of a loss that would be. However, the point stands that competitive situations are structured that way because they motivate people to give it their all.

Now, getting back towards the topic at hand, it seems clear to me that the open-source software world is inherently competitive in nature. Software projects compete to provide the most compelling solution in their problem space. I believe that the competition can (and should) be one of good-natured rivalry, but the logic and structure of this is that it is a competition. It is very largely a healthy competitive spirit that motivates people to excel.

Ego is good?

In a related vein, people will recall that in the film Wall Street, Gordon Gecko famously proclaimed: "Greed is good". This was not an original idea. It is a re-expression of the belief that private vices can lead to public good. The magnate's desire to accumulate wealth is a basic motor that creates wealth for the society as a whole. I realize that there are a lot of caveats to this and I am reluctant to similarly proclaim: "Ego is good." But the reader will have got the idea, I guess.

Sanctimonious political correctness aside, I believe that everybody reading this knows, in their heart of hearts, that a driving force in open-source software development (and in countless other human endeavors) is ego. Narcissism even, if you will. When Muhammad Ali proclaimed "I am the Greatest" he was being outrageously egotistical and narcissistic but at least he was not being a bloody hypocrite about it. I think that was actually refreshing for a lot of people. (Of course, that kind of strutting display has become much more typical in sports, and is probably now just tiresome.)

I would not attempt to deny that ego has been a factor in my work on FreeMarker and in other things that I have done. But that should not be a great revelation. I would say in passing that if a fellow open-source developer told me that ego was not at all a factor in what he did, this would cause me to distrust him; I would assume that he was being less than honest, possibly with himself.

I mean, look, you have to have at least a healthy ego to believe that you have something to offer in a field, that other people have presented a solution but you can improve on it. It takes some belief in oneself to go to the habitual places like usenet groups, javalobby and theserverside and such to announce your work to an audience of software development professionals. People who do this obviously have an ego.

But here is a point about this: when you do this, you must believe that your work is competitive with the state of the art in its space. If there is some other tool that is so unambiguously superior to mine that everybody who uses my tool would be better off using that other tool, I am just wasting people's time. Ego must be tempered by realism; otherwise, it is just narcissistic behavior. If the developers of a tool do not have something to offer that is competitive in its space, that really should lead to a crisis, a moment of reckoning.

The Struts/Webwork Merger

It seems that such a moment of reckoning did occur with Apache Struts. In December 2005, it was announced that the Webwork and Struts community were "merging". What this amounted to was that the the Webwork 2.2 codebase would be used as the starting point for the next generation of Struts, Struts Action Framework 2.

This whole thing came as quite a surprise to me. Not that it really affects me that much, as I don't actually use either tool. My only relationship to the whole thing is that FreeMarker is used quite extensively in Webwork 2.2. The Webwork lead developer, Patrick Lightbody, was a regular on the FreeMarker mailing lists in the latter half of 2005. (He no longer is. He left our community announcing in a huff that he was unsubscribing from our lists. This is clearly somewhat connected with the merger with Struts though it's a bit murky...)

Now, one amazing aspect of this whole thing is that the Struts developers were simply admitting that their product, their community's work, was inferior. While I have misgivings, on which I shall elaborate below, about this "merger", I must give credit where credit is due. The main Struts developers were simply willing to swallow their pride and accept that Webwork was better. Thus, for reasons I outlined above, it simply did not make any sense to continue to promote Struts Classic when people would simply be better off using Webwork.

Yes, the open-source world is competitive by nature, and the Struts people were admitting that they had lost the competition. For the Struts developers to recognize that their users would be better served by migrating to the heretofore competing project is quite admirable.

But now for what I see as the negative aspects...

First of all, Webwork being rechristed Struts TI or Struts something or other is a step that seems designed to mislead the casual observer about what actually happened. Any casual observer would surely assume that this product was the continuation of the Struts 1.x codebase and thus, built on the work of the Struts community. However, this is not the case. There was, de facto, a technically-based competition between the Struts community and the webwork community to produce a better framework. The Webwork people won the competition. The Struts people conceded defeat.

Now, competition is a brutal thing. When I started off this article mentioning the pressures put on these Asian schoolkids, it was not, in my mind, a totally off-topic meandering. Competition is brutal because for somebody to win, somebody else has to lose. And it's humiliating to lose, to the extent that some percentage of those kids actually take their own lives. Since competition is something so inherently hard, we tend to want to find mechanisms to soften things. An athlete who is gracious when he wins and when he loses is admired. This is a mark of maturity certainly, but don't believe that when a highly competitive champion athlete competes and loses, he sleeps well that night. Do not believe that when he smiles and congratulates the winner, that he is not hiding the hurt and shame he feels inside.

I suspect that Niall (the Struts developer with whom I have been having some dialogue on this blog) may now want to jump in and say that my paradigm is wrong, that actually, in this case, everybody won. I would hope though that you don't say this, Niall, because I'm not having any of it. Patrick Lightbody even wrote a blog entry stating "Struts really sucks" and if that's not throwing down the gauntlet, what is? No, there was a technically based competition and you (I mean, the Struts people here) have conceded defeat.

Now, competition is an ugly business, but if you are going to have a competition, it has to be clear who won and who lost. Because let's face it: otherwise, why would anybody bother? So here is what is probably the central objection I have:

This Struts/Webwork merger is designed in such a way as to create a maximum of confusion about who won and who lost.

Actually, the more you look at it, the more ass backwards the whole thing seems. As of this writing, Webwork is one of the projects in the so-called Apache incubator. Webwork's "champion and "mentors" are the principal Struts developers. I ask you: How can Don Brown and Ted Husted or any other of the principal Struts developers be the "mentors" of the Webwork people? They accepted that the Webwork people had actually won the technical competition.

Do I sign up for tennis lessons with a teacher who I just defeated 6-0, 6-0 in a tennis match?

One of the "exit criteria" by which Webwork will be admitted as an Apache project is demonstrating that they "get" the "Apache way". Well, presumably the Struts project was being run in accordance with this "Apache way" yet the Webwork people defeated them in a technically based competition to produce the better framework. So isn't this ass-backwards? If you have a meritocracy where you judge by results, obviously Ted Husted and Don Brown should be trying to learn the "Webwork way" or the "OpenSymphony way" because that is the way that has proven more effective at developing a good framework.

Now, I lurk on the Struts-devel mailing list, mostly just to see if templating issues come up. Some of what I see does amaze me. In this mail Patrick is debating what is basically a second-order project management issue, whether to use email notifications or do things with an RSS feed. (Note that I actually don't have an opinion about this.) One Sean Schofield responded here lecturing Patrick about how mailing lists are "the Apache way" and so on.

The fact is that, given that the Struts people lost the technical competition with Webwork, the only sensible thing is for them to defer to Patrick and the other Webwork people on these issues. If I defeat Joe Blow 6-0, 6-0 in the tennis match, Joe Blow, if he has any sense should not be lecturing me about the "Joe Blow Way" to hit a backhand. That Patrick is able to restrain himself when somebody is lecturing him about "the Apache Way" in this spot shows that he is somebody quite characterologically different from me. I simply would not take such shit from people.

What happens now?

I really don't know. Deep down, Patrick and the other Webwork people must know how absurd the whole situation is. They accept an absurd situation because they want more visibility for their work. I understand. But somehow, I do not think this collaboration is going to work out well. Or, at the very least, I see some rough sailing ahead. I mean, when you set up a situation based on premises that are so divergent from reality -- the people who won the technical competition accepting the people they defeated as their "mentors" -- something maybe has to give at some point. But I don't know for sure either. As Mark Twain (I think it was he) said, making predictions is a perilous business, especially about the future. (Predicting the past is a better bet.)

Well, in closing, one does have to hand it to the Struts people, and ASF in general. You know, it is almost as if, in early 1945, the Germans had managed to convince the allies to unconditionally surrender.

Musings on Wikipedia and Open Source

2006-02-26T20:19:00.000+01:00

Recently, I have been using Wikipedia quite a bit. First off, let me say that Wikipedia really is a blast. It is informative, like a regular encyclopedia, but due to the fact that anybody can contribute, there is a lot of funky stuff there that would not be found in a conventional encyclopedia. Surfing wikipedia is just a whole lot of fun!

Of course, a naysayer would likely interject at this point that if you want to have some fun, go to wikipedia, but if you want complete, reliable information, look at Britannica. I have to admit that this would also be my instinctive reaction. However, much to my surprise (and doubtless that of many other people) a recent study that appeared in Nature magazine found that the accuracy of scientific articles was not significantly different in Wikipedia than in Encyclopedia Britannica. Here is an article on that.

Now, aside from a few very specific topics, like java template engines, or preflop strategy in Omaha Holdem poker, and maybe a couple of other things, I am not really qualified to judge the quality of information in Wikipedia. On the other hand, I have noticed that most Wikipedia articles that I come across are fairly well written. I am sensitive to this and consider myself to be a fairly good judge of it.

I have been thinking about various things regarding open source. It seems to me that Wikipedia's strengths (and weaknesses) as compared to a conventional encyclopedia are pretty much those of the open source development model as compared to conventional software development.

One of the revolutionary aspects of free software is that it drastically reduces barriers to entry. Anybody who is interested and motivated can hack the source code. Similarly, anybody can contribute material to Wikipedia. It seems likely that a conventionally published reference book would have some advantage in quality over the wikipedia model. After all, there is a paid editorial staff that would do systematic fact checking and do some needed line editing and so on. However, the advantage of the wiki model is how flexible it is, how quickly it can admit new material and updates and improvements. For example, if a major scientific discovery is made in a field that invalidates previous theories, it is likely that a wiki-based encyclopedia would incorporate this information much more quickly than a conventional publication. So there is a clear trade-off. In a field as rapidly moving as java software, for example, you might well prefer an article about java development tools that is up-to-date but may contain some errors and bits of sloppy prose over a more polished article on the subject that is a couple of years out of date.

Not long ago, I wrote a blog entry about the issues involved in (very) hypothetically joining Jakarta. Though I answered by way of a simile involving King Arthur and the Round Table, I think that the reasons I gave would be clear to anybody reading it. However, an aspect of this that I did not mention there was that I have gradually come to the conclusion that ASF's entire vision of the open source process is incorrect. Certainly, there are reasons to have severe doubts about it. In recent private correspondence, a java developer commented that, once you got beyond surface impressions and actually rooted around, one could see that over 90% of ASF projects were in some kind of state of hibernation or even severe abandonment. He worried that an open source project that he liked and used quite a bit was on the road to becoming an ASF project, and that this would likely be the kiss of death.

I am not so familiar with that many ASF projects, so I cannot vouch for the 90% figure this person gave. However, I think it's clear that there is some kind of systemic problem.

My considered view is that the root of the problem is that ASF wants to project a certain elitist idea, that becoming a committer on an ASF project is some kind of great honor. If you lurk on a given project's mailing list, you will on occasion see them announce, to great fanfare something like: "John Jones has been accepted as a FooBar committer." This kind of thing has always caused me to roll my eyeballs. The subtext is a bit like so-and-so has been admitted as a high priest who may now enter the inner sanctum and touch the holy of holies (which is the code repository presumably.)

So, until they admit you to the holy of holies, you are basically in some kind of supplicant position: "Please sirs, will you look at my patch." And, of course, since the patch in question is typically something that only that person needs at this moment (or maybe other people need it but none of the committers do) what with one thing and another, they typically don't get around to looking at the guy's patch.

Certainly, the FreeMarker project is not run this way. If somebody expresses some interest in hacking the code, I pretty much immediately offer to add them as a developer so that they can commit code. They are added with no great announcement or votes or fanfare. Note that no vetting has occurred here. I will typically have no objective proof of the person's abilities. It is enough for them to say that they are interested in doing something for me to provide CVS access. Basically, we simply assume that somebody is competent until proven otherwise.

Now, as a practical matter, there is not really much problem with people then turning around and committing poor-quality code willy-nilly. Actually, nine times out of ten, somebody expresses interest in doing something and you give them r/w access to CVS and they just never do anything -- good or bad.

So, people committing all kinds of poor quality code is not a common real-world problem. But it can occur. However, even when it does occur, how much of a problem is it? Somebody does something and you can see what they did and modify their work or completely roll it back. This is, in fact, the whole point of a versions repository, is it not? Since it is fairly easy to roll back the code to some previous known state, why should one be so conservative about letting people commit code?

But again, I think the core problem with ASF is this underlying elitist idea. And I think it's wrong; open source is not elitist by nature. It's more like: "If you can do something, then roll up your sleeves and get to it, let's see what you can do." In other words, a person is assumed to be competent until proven otherwise. The ASF approach seems, on the other hand, to assume that you are not competent to collaborate until somehow proven otherwise. What makes matters worse, though, is that it is not really obvious what people who become committers have done to prove their competence. It often seems to be more of a popularity contest with people voting +1 and so on.

So, admittedly, another take on this is that the problem is perhaps not elitism per se, but elitism that is arbitrarily applied. If you're going to be elitist, you should at least have some objective criteria.

The other aspect of this that I think is quite worthy of comment and some analysis is that, as far as I can see, the projects that line up to join ASF are not doing so because they really believe that there is any technical value in it. It is purely to leverage the Apache brand name and thus take advantage of those placement and visibility advantages. Now, if you look at the pages relating to the Apache incubator, they state the supposed technical advantages that getting in with ASF involves, access to world experts in specific domains, experts in running open source projects, etcetera. But again, I do not believe that the OSS projects that want to get on apache.org believe any of this. It's purely for the visibility. For example, when the Struts/Webwork merger was discussed on opensymphony.com forums, the argument used was that by merging with Struts, they would get WebWork's technical superiority along with Struts's "community". I parsed "community" in this case to be code for the marketing advantages. (In general, "community" is a term that ASF people use frequently in an odd and somewhat mystical way.)

I do not recall that anybody suggested that the Struts people had anything to offer technically. Zero, zilch, squat. Of course, similarly, when Leos Literak asked me about the possibility of joining ASF, it was all about publicity, he never at any moment in the discussion suggested that ASF had anything to offer us on a technical level.

Well, all of this does introduce a real element of moral hazard. If you join ASF purely because so many people believe in this "Apache mystique" (that you, yourself do not believe in) then you now have a vested interest in perpetuating said mystique, since, after all, your whole strategy was based on the continuation of this mystique.

As a final note on this "Apache mystique", if what my correspondent said, that over 90% of ASF projects are in a sad state of neglect, a great gap has opened up between hype and reality. A very huge gap indeed. Is such a situation sustainable long-term? You know , it may be analogous to what happens in a financial boom, where something like internet stocks, say, get priced at some level completely out of line with whatever real economic value these things have. Such booms ultimately lead to a day of reckoning, a crash. When exactly such a crash occurs is all in the sort of theory of tipping points, etcetera. Or maybe there won't be any such "crash". Still, my sense of things is that this Apache mystique will ultimate end up being deflated significantly.

Well, nothing is more humbling than trying to predict the future. I have no crystal ball. We shall see.

Getting back in the Groove

2006-02-20T17:24:00.000+01:00

Over the last couple of years, I have been doing fairly little in software development. My main activity has been online poker. I see little reason to keep this much of a secret.

Nonetheless the itch to do some coding has resurfaced (maybe it's in the blood, like a virus or something) and I decided to get back in the groove, as it were. Aside from getting more involved in FreeMarker again, I began writing some poker-related code. The current (still very green) state of things is on sourceforge.

Ruby

I originally decided to use the pokersim project as a basis to explore Ruby. So I started the pokersim code in Ruby and made very fast progress despite the huge holes in my knowledge of the language.

At some point, however, I decided, on a whim, to port the code over to Java, to compare performance as well as certain code metrics. I'll cut to the chase quickly and say that the same code (algorithmically the same code, it's different code obviously) ran 10x faster in Java. To be fair, this is because of the advanced JIT technology in Java. If you run with the JIT compiler disabled, the interpreted Java bytecode runs approximately at the same speed as the Ruby code. I am not enough of a compiler wonk to know whether the Ruby bytecode is as optimizable in theory as the Java bytecode, or in other words, whether the kind of tricks that Hotspot and its brethren do could be replicated in the Ruby world. (Perhaps not, due to Ruby's much more dynamic nature, but I don't know for sure either.)

In any case, I am really a practitioner in this field, not a theoretician, and I have to work with the tools available rather than theorize about what tools are possible. I wanted to write software that could generate a lot (like maybe some tens of thousands) of random poker deals and generate statistics. While, to be honest, I'm still not sure about the exact application, it is clear that, while 2x or 3x difference might not be so dramatic, a 10-fold speed difference could make huge differences in the usability of any software that comes out of this.

I decided to switch the project over to Java. If I take another run at Ruby, it will be when I have defined some project where I know performance is not critical. (Or it could be that, at some future point in time, Ruby performance will be much better.)

Java 1.5 and Generics

So now, rather than using pokersim as a testbed for learning Ruby, I decided to use it to explore new features in Java 1.5, in particular type-safe enums, generics, and so on.

The type-safe enum introduced in java 1.5 is unreservedly wonderful. In 1999 or 2000 I remember writing a type-safe enum class that worked in a very similar way to the way java 1.5 enums work. However, it was not part of the language, so it was much much more awkward to use.

I also started using the genericized containers in java.util.*. The main advantage of generics is notational convenience. The type-safety issue is mostly an ersatz problem. The reason is that you very rarely in my experience have a heterogeneous container anyway. For example, if the cards object below is a regular untyped ArrayList from pre-1.5 java, you might write something like:


for (Iterator it = cards.iterator(); it.hasNext();) {
   Card card = (Card) it.next();
   ...
}

The argument that the (Card) typecast is somehow unsafe is, to my mind, merely a theoretical argument. As a practical matter, the real problem with ungenericized code like that above is its extreme verbosity. In pokersim code, I have a Cards class which is basically a ArrayList with a bunch of convenience routines.


public class Cards extends ArrayList<Card> {
  ...
}

and now I can write instead:


for (Card card : cards) {
   ...
}

And of course, the card variable is already defined within the loop. The whole thing is much more pleasant. It is shorter to type, it is easier to read and see the intent. Since such loops occur all over the place in the code, it makes a huge difference to code readability. It is already not too much worse than python code such as:


for card in cards :
  ....

The above is, I guess, notational nirvana. Is there any cleaner more economical way to express the idea that you are iterating over the elements in a container? The java code still has significant visual clutter, the ( and ) and { and }, delimiters that python does without. Python (and Ruby) are still much nicer languages to write (and read) code in. The generics in java 1.5 simply reduce the gap somewhat.

But again, the practical advantage of the generics here is, in my view, entirely on a notational level. The type-safety argument that is often harped on when generics are discussed strikes me as mostly an ersatz issue. Code throwing ClassCastException when you cast taking them out of containers was never that much of a problem in pre-1.5 java code.

Eclipse

Another thing in that I have started using the Eclipse IDE for my java coding. Even aside from the tool's intrinsic merits, simply the fact that my main FreeMarker collaborators (Attila, Daniel, Stephan) use Eclipse is a major consideration, and I had taken various runs at using it before. However, until now, I had never been able to keep using it. I always ended up switching back to using jEdit (along with certain key plugins like XRefactory and AntFarm) as well as a whole hodgepodge of little scripts I used from the command-line, using a lot of grep and find and so on. I actually recognized that this was a more retrograde approach, but I still abandoned Eclipse each time.

But now I am using Eclipse and there is little likelihood that I am going back.

Perhaps the main reason that I have moved to Eclipse this time for good (as compared to previous runs) is that I am running better hardware. I bought a new Dell Inspiron 9300 last September. My previous memories of using Eclipse were that it was just so monolithic and slow. Also, I am simply running the Windows XP that came with the Dell and in previous runs, I was running Eclipse on Linux, where Java is much less performant. In particular, memory usage was just frightening on linux.

Eclipse itself may have got better as well, as well as the underlying JVM. But for whatever reasons, it was mainly that the thing was such a hog that, while recognizing the tool's virtues, I couldn't use it; it just drove me nuts.

But that was then and this is now. Consider me an Eclipse convert. Eclipse is also a good argument for Java over Ruby or Python, say. I do not believe the latter have development environments that are comparable.

Google doesn't index us...

2006-02-17T09:43:00.000+01:00

Google doesn't index freemarker.org for years, probably because of the domain name hijacking issue earlier, where someone has run a porn linkpark on that domain. So we didn't stopped using freemarker.sourceforge.net since then, because that's at least indexed by google. But the google rank of a page is mostly calculated based on how many external links point to it. Since our official homepage is freemarker.org, most external links will use that domain name, hence those links are all wasted as far as we are talking about google rank. Given that how critical factor google rank is for your visibility, I see this as a serious loss.

Some comments on joining Jakarta (or not)

2006-02-16T22:10:00.000+01:00

A longtime FreeMarker user, Leos Literak, asked on our mailing list about the possibility of our joining Jakarta/ASF. I figured that by answering on this blog rather than on the list, I could kill two birds with one stone -- I could answer him and inaugurate this blog with something (hopefully amusing) for people to read.

I guess Leos knows that such a move is highly unlikely, if only on account of the less than cordial relations that some of us have with some of the Jakarta/ASF people. But that is only part of it, at least speaking for myself. Other FreeMarker developers may not share my views (or share them partially with some nuances.) But in any case, I am only speaking for myself.

Okay, I shall assume that the reader is familiar with the Arthurian legends (you know, Camelot, Excalibur, the Round Table) through one or more of its literary, or more likely, cinematographic adaptations. Let us say that I am a knight of that time period, known for certain knightly deeds. It is proposed that I should try to become admitted to the Round Table, to become one of the famed Knights of the Round Table.

I have to admit that the idea has certain appealing aspects. You see, there is a whole mystique around the Round Table. This is mainly because there is a whole legion of wandering troubadours who go about the land singing epic songs about their heroic exploits. This has a lot of advantages. It seems that if you are a Knight of the Round Table, you are given the choicest morsels at feasts. When you show up somewhere, they break out the best wines and spirits to celebrate that such a hero is gracing their presence. The fairest maidens of the land fall at your feet.

So it would seem to be an easy decision. However, there is a dark side to all of this. You see, suppose that you happen to know that the Round Table mystique is based on quite little. On the contrary, these Knights of the Round Table are, in reality, quite the motley crew. Some are not such bad fellows, but many others are thugs and cutthroats and others are cowardly bullies. To your mind, King Arthur himself is no more admirable than any other mafia boss trying to expand his territory. (As a side note, while I grant that I was not there, this version of things strikes me as being at least as likely to be true as the legends.)

Suppose that I don't accept Arthur as a legitimate king. (For example, I happen to know for a fact that when he pulled the sword out of the stone, it was a cheap sleight of hand trick.) However, to become a Knight of the Round Table, I must kneel before him and accept him as my sovereign. I will probably also have to retract any prior statements I made about the supposed exploits of the Knights of the Round Table. I would now have to toe the party line (sorry for the mixed metaphors...) regarding the heroic exploits of my colleagues of the Round Table. (Actually, for an example of this, see here.)

Well, in summary, like any decision it would have its pros and cons to weigh. The pros mainly involve all the troubadours wandering about singing your praises. (I guess the modern equivalent is all the computer magazines and the various people who write O'Reilly books about any load of horse manure that ASF tosses over the fence...) The cons involve compromising one's integrity by accepting illegitimate authority, and also having to be nice and behave respectfully to people you don't particularly like or respect.

I guess the reader has already inferred that, for me, given my characterological makeup, the cons outweigh the pros -- to an extent that it is basically unthinkable.

All of that said, I can respect that other people would see things differently. Certainly, many other open source projects are extremely eager to become ASF projects and I can respect their reasons. It may well be a weakness of overweened pride on my part that I am not willing to kowtow to authority that I perceive to be illegitimate. It certainly is not particularly pragmatic.

Feature in spotlight: Error reporting

2006-02-14T21:17:00.000+01:00

Max Rydahl Andersen, a Hibernate developer tells us "A story about FreeMarker and Velocity" on the Hibernate groupblog. It is later covered on TheServerSide.com as well. Looks like that the one feature among all things that particularly convinced Max to abandon Velocity and start using FreeMarker was - drumroll - error reporting. Now, error reporting is not a functionality that's usually prominently displayed on a product's feature sheet, yet if done right it is invaluable for time efficient problem solving when things go wrong.

So, what's it all about?

Well, it works like this: when FreeMarker encounters an error, it'll not only pinpoint the exact column and line where the error occurred, but it will display a full template stack trace containing all macro invocations and includes that led to the point of exception. To illustrate it with an example, consider we have two templates, a.ftl and b.ftl:

a.ftl:


<#include "b.ftl"/>

b.ftl:

 
<#macro printFoo y> 
${y.foo} 
</#macro>

<@printFoo bar/>

Then you'll see this output (assuming your error was that "bar" is a simple string instead of a hash):


Expected hash. y evaluated instead to freemarker.template.SimpleScalar
on line 2, column 3 in b.ftl. 
Quoting problematic instruction: 
---------- 
==> ${y.foo} [on line 2, column 1 in b.ftl] 
in user-directive printFoo [on line 5, column 1 in b.ftl] 
in include "b.ftl" [on line 1, column 1 in a.ftl] 
----------

So you can see precisely what template execution path led to the error - invaluable to figure out what's going on when you can have macros and includes invoked from multiple locations.