Stephen, Roger,
Thanks for reviews. This has been pushed to jdk9-dev.
Regards, Peter
On 04/30/2015 02:47 PM, Roger Riggs wrote:
Hi Peter,
Yes, go ahead with the patch as is.
Thanks, Roger
On 4/30/2015 6:24 AM, Peter Levart wrote:
On 04/29/2015 05:35 PM, Roger Riggs wrote:
Hi Peter,
On 04/29/2015 05:35 PM, Roger Riggs wrote:
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 approach works for me, and the patch is valid as is.
Stephen
On 30 April 2015 at 11:24, Peter Levart peter.lev...@gmail.com wrote:
On 04/29/2015 05:35 PM, Roger Riggs wrote:
Hi Peter,
There should be two changesets; so pretend the truncation has been
performed for this change.
It
Hi Peter,
Yes, go ahead with the patch as is.
Thanks, Roger
On 4/30/2015 6:24 AM, Peter Levart wrote:
On 04/29/2015 05:35 PM, Roger Riggs wrote:
Hi Peter,
There should be two changesets; so pretend the truncation has been
performed for this change.
It maybe useful to backport the
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
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
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
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
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 https://bugs.openjdk.java.net/browse/JDK-8079063
ZoneOffsetTransition constructor should ignore nanoseconds
With that, the compareTo method
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 https://bugs.openjdk.java.net/browse/JDK-8079063
ZoneOffsetTransition constructor should ignore
Hi Peter,
Caching the epochSecond moves the computation from a relatively lazy version
to creation when it would be performed eagerly for every transition.
Is there a quick way to see if it will have an impact on the startup time?
Roger
On 4/27/2015 12:24 PM, Peter Levart wrote:
Hi again,
One additional change is needed. The compareTo() method can rely on
the new epochSecond field as well.
Otherwise good!
Stephen
On 27 April 2015 at 17:24, Peter Levart peter.lev...@gmail.com wrote:
Hi again,
Here's another optimization to be reviewed that has been discussed a while
ago (just
Hi again,
Here's another optimization to be reviewed that has been discussed a
while ago (just rebased from webrev.01) and approved by Stephen:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
The discussion about it is intermingled with the
TzdbZoneRulesProvider parses the byte[] of TZ data on demand when a
ZoneId is first requested. So, the ZoneOffsetTransition will not be
created unless a ZoneId is during startup.
Stephen
On 27 April 2015 at 22:58, Roger Riggs roger.ri...@oracle.com wrote:
Hi Peter,
Caching the epochSecond
14 matches
Mail list logo
