Bulk backports request of java.time bug fixes to jdk8u

roger riggs roger.riggs at oracle.com
Mon Apr 7 19:38:46 UTC 2014


ok, I'll wait a bit to see if there are any concerns.

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




More information about the jdk8u-dev mailing list