Re: RFR: 8077685: (tz) Support tzdata2015d

Looks good to me. Masayoshi On 4/29/2015 11:37 PM, Aleksej Efimov wrote: Hi, Please, review the fix for adding the latest tzdata2015d to JDK9. The JTREG and JPRT tests were executed. No failures were observed. Thank you, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685 [2] W

Re: [9] RFR of 8078672: Print and allow setting by Java property seeds used to initialize Random instances in java.lang numerics tests

Hi Joe, On Apr 29, 2015, at 4:26 PM, Joseph D. Darcy wrote: > Sounds reasonable (they two files didn't necessarily look related, but I > thought it was worth checking). I understand: that’s just being thorough! Thanks, Brian

Re: [9] RFR of 8078672: Print and allow setting by Java property seeds used to initialize Random instances in java.lang numerics tests

Hi Brian, On 4/29/2015 4:25 PM, Brian Burkhalter wrote: Hi Joe, No, RandomFactory would have been added by the previous webrev.00 version of the patch, i.e., RandomFactory did not come from RandomSeed. Is this reasonable? Thanks, Sounds reasonable (they two files didn't necessarily look

Re: [9] RFR of 8078672: Print and allow setting by Java property seeds used to initialize Random instances in java.lang numerics tests

Hi Joe, No, RandomFactory would have been added by the previous webrev.00 version of the patch, i.e., RandomFactory did not come from RandomSeed. Is this reasonable? Thanks, Brian On Apr 29, 2015, at 4:03 PM, joe darcy wrote: > Looks good. If the new RandomFactory.java came from the old Ran

Re: [9] RFR of 8078672: Print and allow setting by Java property seeds used to initialize Random instances in java.lang numerics tests

Hi Brian, Looks good. If the new RandomFactory.java came from the old RandomSeed, it would be preferable if the old file was hg mv'ed to the new one. Thanks, -Joe On 4/29/2015 3:55 PM, Brian Burkhalter wrote: Continuing the conversation about: https://bugs.openjdk.java.net/browse/JDK-80786

Re: [9] RFR of 8078672: Print and allow setting by Java property seeds used to initialize Random instances in java.lang numerics tests

Continuing the conversation about: https://bugs.openjdk.java.net/browse/JDK-8078672 with an updated patch: http://cr.openjdk.java.net/~bpb/8078672/webrev.01/. Please review at your convenience. Summary: 1) test/java/lang/RandomFactory.java is moved to test/lib/testlibrary/jdk/testlibrary/ (w

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

Hi Peter, There should be two changesets; so pretend the truncation has been performed for this change. It maybe useful to backport the performance improvement to jdk 8 but the spec change will have to be in 9 (or wait for a maintenance release). The simplification of toInstant can happen wit

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

On 04/29/2015 03:31 PM, Roger Riggs wrote: Hi Peter, Point taken about the constructor and that should have a spec clarification to ignore the nanoseconds. The issue is tracked with: JDK-8079063 ZoneOffsetTransition constructor should ignor

RFR: 8077685: (tz) Support tzdata2015d

Hi, Please, review the fix for adding the latest tzdata2015d to JDK9. The JTREG and JPRT tests were executed. No failures were observed. Thank you, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685 [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015d/9/00

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

Hi Peter, Point taken about the constructor and that should have a spec clarification to ignore the nanoseconds. The issue is tracked with: JDK-8079063 ZoneOffsetTransition constructor should ignore nanoseconds With that, the compareTo metho

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

Hi Stephen, Peter, I think we should clarify the constructor to indicate that nanoseconds are truncated/ignored. That should be done as a separate request since it is a spec change and needs additional review. Roger On 4/29/2015 5:43 AM, Stephen Colebourne wrote: On the LocalDateTime being

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

On the LocalDateTime being passed in with nanoseconds, that was an unconsidered use case. The whole offset system relies on second based offsets, so it should really be validated/truncated to remove nanos. That way the equals/compareTo could be simplified again. Seems like a separate issue, but per

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

On 04/27/2015 06:51 PM, Stephen Colebourne wrote: One additional change is needed. The compareTo() method can rely on the new epochSecond field as well. Otherwise good! Stephen Hi Stephen, LocalDateTime (transition) has nanosecond precision. It may be that transitions loaded from file in Zon