Re: [Freemarker-devel] Java 8 java.time support in FreeMarker 2

[Geoffrey De S. <ge0...@gm...>]

> 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?

I think you only need 1 new class: TemporalTemplateModel (or 
TemporalAccessorTemplateModel), not 12+.

All those 12+ java.time objects implement the interface Temporal and 
TemporalAccessor.
For example, LocalDate implements Temporal and TemporalAccessor
DateTimeFormatter is the class to parse and format (so read and write) 
any of those 12 temporal types.

Writing any such type is easy with 
DateTimeFormatter.format(TemporalAccessor):
DateTimeFormatter dateTimeFormatter = 
DateTimeFormatter.ofPattern("yyyy-MM-dd hh:mm:ss")
// Landed on moon on 1969-07-20
String s1 = "Landed on moon on " + 
dateTimeFormatter.format(LocalDate.of(1969,7,20));
// Landed on moon at 1969-07-20 20:18
String s2 = "Landed on moon at " + 
dateTimeFormatter.format(LocalDateTime.of(1969,7,20,20,18);


https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html

https://docs.oracle.com/javase/8/docs/api/java/time/temporal/Temporal.html

https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html