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