Manfred-
Yes, I will prototype the solution. Thanks again
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 1:22 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> 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
> 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 <%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> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>