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