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
