Java 8 java.time support in FreeMarker 2

[Daniel Dekany <dd...@freemail.hu>]

I was thinking about how to support the time API introduced in Java 8
(JSR-310). It's on the Contributors Wanted page for a long time, and
now we also have a Jira request for it
(https://issues.apache.org/jira/browse/FREEMARKER-35).

(There's also this: https://github.com/amedia/freemarker-java-8 This
doesn't expose the Java API of the objects, but add a few own methods,
most importantly "format".)

I think that we shouldn't support the java.time types specifically. We
hardly want to add 12+ new TemplateModel-s for them
(InstantTemplateModel, DurationTemplateModel, LocalDateTemplateModel,
MonthDayTemplateModel, etc.), and I think that a such complex and
platform specific thing shouldn't be part of the FTL type system
anyway. Consistently with that decision, we wouldn't replicate the
methods of these things with built-ins either (especially as templates
mostly only meant to display these objects). So java.time objects
should just fall into the same category as any random application
specific class. Thus the DefaultObjectWrapper will expose their Java
API-s too, so you can automatically write someLocalDate.year or even
someLocalDate.plusDays(1). (Out-of-the-box you won't be able to pass
in enums though...) What this so far doesn't solve is formatting. For
that, we should improve on how one can format objects of any "random"
class. So the user should be able to configure FM so that instances of
an user-specified class can be formatted with ?string(...), and also
can have a default format specified (similarly to number_format,
date_format, etc.). So it's the same logic that we have for numbers
and pre-java-8 date-s, only extended to any classes.

We still have to "cheat" a bit. If FreeMarker runs on Java 8, it
should pre-configure itself to deal with those 12+ java.time classes
(otherwise the user had to copy-paste some long configuration
fragment). Also we should add a few variation of `.now` that returns
the value with Java 8 types.

What do you think about this approach?

-- 
Thanks,
 Daniel Dekany