Bulk backports request of java.time bug fixes to jdk8u

[Seán Coffey]

Good to hear Roger! Thanks for following up.

Approved for jdk8u-dev.

regards,
Sean.

On 11/04/14 15:08, roger riggs wrote:
> Hi Sean,
>
> The challenge to the two tests is successful and the exclusions have 
> been added to the jdk8 exclude list.
>
> I verified that the excluded tests fail on the current (incorrect) 
> implementation and
> have been excluded.
>
> Please approve.
>
> Thanks, Roger
>
> On 4/7/2014 3:26 PM, Seán Coffey wrote:
>>
>> On 07/04/14 18:41, roger riggs wrote:
>>> Hi Sean,
>>>
>>> I've checked with the JCK team on all the tck tests that have changes.
>>> For 8036818, the JCK test has been challenged since it is incorrect 
>>> according to the spec;
>>> I expect it will be excluded.
>> Thanks for the update. If it's ok, can we hold off pushing these 
>> changes for a few
>> days and see if the JCK team approve the exclusion request ?
>>
>> regards,
>> Sean.
>>>
>>> The new tests for various corrections are to be used only as unit 
>>> tests for 8
>>> unless they match the formal JSR310/JDK 8 specification and pass 
>>> using the official JDK RI.
>>> Those tests can be considered to fill coverage 'gaps' if/when the 
>>> JCK is updated.
>>>
>>> Paul can clarify if I'm mistaken about what needs to be done.
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 4/7/2014 12:51 PM, Seán Coffey wrote:
>>>> Hey Roger,
>>>>
>>>> so some of these changesets touch the JSR310 TCK tests. Can you 
>>>> confirm that the Java 8 TCK tests still pass with the changes made 
>>>> ? If not, we'll need to request that some be excluded and provide 
>>>> justification before any such change would go into jdk8u.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>> On 07/04/14 15:32, roger riggs wrote:
>>>>> Hi,
>>>>>
>>>>> Please consider the following bugs/corresponding changesets for 8u.
>>>>>
>>>>> They are in jdk 9 and apply cleanly as is and have passed JPRT.
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cc1e17f7848c
>>>>>  8036818: <https://bugs.openjdk.java.net/browse/JDK-8036818> 
>>>>> DateTimeFormatter withResolverFields() fails to accept null
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0312741183c9
>>>>> 8032502 <https://bugs.openjdk.java.net/browse/JDK-8032502>: 
>>>>> java.time add @param tags to readObject
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/784ab0cb4874
>>>>> 8035106 <https://bugs.openjdk.java.net/browse/JDK-8035106>: Typo 
>>>>> in java.time.format.Parsed error message
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/357781084a1b
>>>>> 8032491 <https://bugs.openjdk.java.net/browse/JDK-8032491>: 
>>>>> DateTimeFormatter fixed width adjacent value parsing does not 
>>>>> match spec
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21bdd212f727
>>>>> 8036785 <https://bugs.openjdk.java.net/browse/JDK-8036785>: 
>>>>> ChronoLocalDate refers to generics that have been removed
>>>>>
>>>>> changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd255db6c0d0
>>>>> 8035099 <https://bugs.openjdk.java.net/browse/JDK-8035099>: 
>>>>> LocalTime.with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect
>>>>>
>>>>> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dc0edff71f1c
>>>>> 8032749 <https://bugs.openjdk.java.net/browse/JDK-8032749>: Typo 
>>>>> in java.time.Clock
>>>>> 8032888 <https://bugs.openjdk.java.net/browse/JDK-8032888>: Error 
>>>>> message typo in TemporalAccessor
>>>>> 8032558 <https://bugs.openjdk.java.net/browse/JDK-8032558>: 
>>>>> Instant spec includes incorrect assertion wrt valid range
>>>>> 8032494 <https://bugs.openjdk.java.net/browse/JDK-8032494>: 
>>>>> DateTimeFormatter spec includes irrelevent detail on parsing pattern
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>
>>>
>>
>