Hi Josh / Kito,
Please be aware that backward compatibility would prevent us from change
the default return type of the DateTimeConverter.
Josh, could look into prototyping the conversion of a LocalDateTime
keyed of the "type" attribute with value "localDateTime"
for the DateTimeConverter?
Thanks!
Kind regards,
Manfred Riem
On 9/3/15, 12:32 PM, Josh Juneau wrote:
> Kito,
>
> Thanks for the input. I think that LocalDateTime is probably the
> closest to the current java.util.Date, in that it is comparable to a
> timestamp. The only issue with defaulting to LocalDateTime is that
> anyone using JSF 2.3 would then be required to use JDK8. I think we
> may want to default to java.util.Date for backward
> compatibility unless otherwise specified using an attribute on the
> component and/or Faces converter.
>
> If we are targeting JDK 8 for this release, then we could certainly
> default to the LocalDateTime.
>
> Thanks
>
> Josh Juneau
> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Thu, Sep 3, 2015 at 12:10 PM, Kito Mann <kito.mann_at_virtua.com
> <mailto:kito.mann_at_virtua.com>> wrote:
>
> I haven't worked with the new date/time API yet. Is there one
> implementation that serves like 80% of the use-cases? If so, it
> might make sense to default to it.
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> http://www.JSFCentral.com | @jsfcentral
> +1 203-998-0403 <tel:%2B1%20203-998-0403>
>
> * Listen to the Enterprise Java Newscast: _http://
> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
> <http://ww.enterprisejavanews.com>_
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>
> On Thu, Sep 3, 2015 at 12:49 PM, Josh Juneau <juneau001_at_gmail.com
> <mailto:juneau001_at_gmail.com>> wrote:
>
> Thanks Manfred, I appreciate the feedback.
>
> I agree that simpler is better...the context parameter would
> provide a single switch to flip for enabling the JDK 8
> Date-Time functionality for an application. However, since
> there are several Date-Time implementations, it makes sense to
> handle each use-case individually, rather than at an
> application level. If we are going to require the
> specification of the "type" attribute anyways, then it makes
> sense to forget about the context parameter.
>
>
>
> Josh Juneau
> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Thu, Sep 3, 2015 at 10:59 AM, manfred riem
> <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>
> Hi Josh,
>
> I rather not introduce a context-param.
>
> Can we utilize the "type" attribute and add "localDate",
> "localDateTime" and so on as the type.
>
> Then augment the existing implementation to take advantage
> of the JavaSE 8 corresponding types?
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 9/3/15, 5:11 AM, Josh Juneau wrote:
>> Everyone, the following is my proposed solution for the
>> issue: JAVASERVERFACES_SPEC_PUBLIC-1370
>> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370>
>>
>>
>> Main idea, load the specified Date-Time converter for a
>> given date field, as per the blog post:
>> http://jj-blogger.blogspot.com/2015/06/utilizing-java-8-date-time-api-with-jsf.html
>>
>>
>> Proposal for specifying the date type for an application
>> or UIComponent:
>> Create javax.faces.DATE_TIME context parameter at the
>> application level, accepting the following values:
>> JDK7 (default) - this will use the java.util.Date as it
>> is used now
>> JDK8 - this will force converters and components to
>> utilize the new Date-Time API
>>
>> [ (the following values are not my recommended approach,
>> but also a possibility)
>> JDK8.LocalDate - utilize the LocalDate implementation
>> JDK8.LocalDateTime - utilize the LocalDateTime
>> implementation only
>> JDK8.LocalTime - utilize the LocalTime implementation only
>> JDK8.OffsetTime- utilize the OffsetTime implementation
>> only
>> JDK8.OffsetDateTime - utilize the OffsetDateTime
>> implementation only
>> ** It is possible to include these values at the context
>> parameter level to enable only the specified Date-Time
>> classes for an application, but this would limit every
>> date within the scope of the application to only the
>> specified value.
>> ]
>>
>> The preferred solution for specifying the Date-Time
>> implementation within the context parameter would be to
>> require component libraries to add a new attribute to the
>> calendar component “type” to allow specification of the
>> conversion type (LocalDate, LocalDateTime, LocalTime,
>> OffsetTime, OffsetDateTime). An alternative possibility
>> is to make use of the existing “converter” attribute on
>> many calendar components (ie. PrimeFaces calendar
>> component) to choose the preferred implementation. We
>> will need to generate a FacesConverter for each of the
>> converter implementations.
>>
>> javax.faces.convert.DateTimeConverter should have a new
>> converter along side, as mentioned by Ed in the issue
>> comments. This converter should be named
>> NewDateTimeConverter to represent the “New” date-time
>> API. The convertDateTime tag should contain a new
>> attribute “type” that can be used to specify the
>> implementation that will be utilized by the
>> NewDateTimeConverter class. The possible values for
>> type (LocalDate, LocalDateTime, LocalTime, OffsetTime,
>> OffsetDateTime).
>>
>> Please review and provide feedback. Thanks for your time.
>>
>> Josh Juneau
>> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Tue, Sep 1, 2015 at 9:06 AM, Josh Juneau
>> <juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>> wrote:
>>
>> Hi Manfred-
>>
>> To be honest, I haven't begun working on the
>> implementation yet, as I've been finishing up an
>> article for Java magazine. I am submitting that
>> today, so this is next on the list. I have thought a
>> lot about it and have some ideas of how we can
>> possibly support 1.8 date and time as well as
>> backwards compatibility. I will start there...I will
>> send out my proposed ideas to the list within the
>> next day.
>>
>> Main idea, add a new Faces parameter in web.xml to
>> configure JDK date preference. Another option is to
>> add an attribute to the calendar components that will
>> allow for backward compatibility...but support JDK8
>> date and time by default. This will be the main
>> discussion, I believe...which to make default. If we
>> make JDK8 default then it will break all applications
>> right away...but if we make JDK8 opt-in, then it may
>> be easier to push through.
>>
>> Thanks
>>
>> Josh Juneau
>> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Tue, Sep 1, 2015 at 8:52 AM, manfred riem
>> <manfred.riem_at_oracle.com
>> <mailto:manfred.riem_at_oracle.com>> wrote:
>>
>> Hi Josh,
>>
>> How is the issue going?
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 8/24/15, 2:01 PM, Josh Juneau wrote:
>>> Hi Manfred-
>>>
>>> Hope all is well! Certainly...please do assign
>>> it to me and I'll take a crack at it.
>>>
>>> Thanks for your time, it is appreciated.
>>>
>>> Josh Juneau
>>> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>>> http://jj-blogger.blogspot.com
>>> https://www.apress.com/index.php/author/author/view/id/1866
>>>
>>>
>>> On Mon, Aug 24, 2015 at 1:42 PM, manfred riem
>>> <manfred.riem_at_oracle.com
>>> <mailto:manfred.riem_at_oracle.com>> wrote:
>>>
>>> Hi Josh,
>>>
>>> Can I assign this to you?
>>>
>>> See
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370
>>>
>>> It should be fairly straightforward.
>>>
>>> Thanks!
>>>
>>> Kind regards,
>>> Manfred Riem
>>>
>>> On 8/18/15, 3:51 PM, Edward Burns wrote:
>>>
>>> Hello Volunteers,
>>>
>>> Fellow EG member Josh Juneau has written
>>> a blog post about this, but to
>>> actually do it in the spec we need a lot
>>> more. I see that Cody Lerum
>>> has filed issue 1370 about it so let's
>>> use that. Can someone step up
>>> and make a concrete proposal about how
>>> to do this?
>>>
>>> Thanks,
>>>
>>> Ed
>>>
>>>
>>
>>
>
>
>