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