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