[jira] [Commented] (TAP5-2645) Java Time API / JSR310 Type Coercers

["Benjamin Weidig (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240241#comment-17240241 ] 

Benjamin Weidig commented on TAP5-2645:
---------------------------------------

I've updated the patch, and added some documentation that might be added to the Tapestry TypeCoercer documentation.

The TypeCoercers are now better grouped, and use method references or lambdas, to better utilize the JVM instruction "invokedynamic".

 

 

> Java Time API / JSR310 Type Coercers
> ------------------------------------
>
>                 Key: TAP5-2645
>                 URL: https://issues.apache.org/jira/browse/TAP5-2645
>             Project: Tapestry 5
>          Issue Type: Improvement
>            Reporter: Benjamin Weidig
>            Priority: Minor
>         Attachments: TAP5-2645-Documentation.md, TAP5-2645.diff
>
>
> h1. Summary
> Add JSR310 / Java Time `CoercionTuple`s to Tapestry.
> h1. Goals
> With Tapestry 5.5.0 elevating the minimum Java version to 1.8, it should provide `CoercionTuple`s for the new Java Time API ([JSR310]([https://jcp.org/en/jsr/detail?id=310)):]
>  * Add a `CoercionTuple` for all relevant types
>  * Add specific tuples to reduce possible mismatches
> h1. Motivation
> Type coercion is deeply ingrained in Tapestry.
>  And therefore it should be as mature and complete as possible for its Java version.
> The addition of the Java time API is a well thought-out replacement for the previous limited `java.util.Date`-/`java.util.Calendar`-based approach.
>  By adding type coercion for the new types we could encourage developers to use them in their code, instead of working around them missing, or needing to provide their own implementation.
> h1. Risks and Assumptions
> None to minimal risk is assumed.
> For Tapestry itself, no risk can be assumed.
>  Existing type coercers won't be changed, only new ones added.
> For user projects a minimal risk of duplicate type coercers exist.
>  Due to the implementation of `org.apache.tapestry5.ioc.internal.services.TypeCoercerImpl` 
>  user type coercers will override the newly provided ones.
> h1. Alternatives
> Instead of automatically including the type coercers we could lock them behind a feature-flag.
> h1. Details of Proposed Changes
> The Java Time API has well-defined `toString()` methods, so we don't need explicit `Type.class --> String.class` coercers.
> Additional type coercers are needed for type-downgrade (`LocalDateTime.class --> LocalDate.class`), due to possible parsing exception between different `String`-based output formats.
> Following type coerces will be added:
>  
> {code:java}
> * Year --> Integer
> * Integer --> Year
> * Month --> Integer
> * Integer --> Month
> * Month --> String (enum)
> * String --> Month (enum)
> * String --> YearMonth
> * YearMonth --> Year
> * YearMonth --> Month
> * String --> MonthDay (enum)
> * MonthDay --> Month (enum)
> * DayOfWeek --> Integer
> * Integer --> DayOfWeek
> * DayOfWeek --> String
> * String --> DayOfWeek
> * String --> LocalDate
> * LocalDate --> YearMonth
> * LocalDate --> MonthDay
> * LocalTime --> Long
> * Long --> LocalTime
> * String --> LocalTime
> * String --> LocalDateTime
> * LocalDateTime --> LocalDate
> * String --> OffsetDateTime
> * OffsetDateTime --> OffsetTime
> * String --> ZoneId
> * String --> ZoneOffset
> * String --> ZonedDateTime
> * ZonedDateTime --> ZoneId
> * Instant --> Long
> * Long --> Instant
> * Duration --> Long
> * Long --> Duration
> * String --> Period
> {code}
> h1. Testing
> All added functionality will be unit tested.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)