You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Benjamin Weidig (Jira)" <ji...@apache.org> on 2020/10/16 07:39:00 UTC

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

Benjamin Weidig created TAP5-2645:
-------------------------------------

             Summary: 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


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)