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 wrote:
> Hi Peter,
>
> Caching the epochSecond moves the computation fr
Hi Roger,
I think you meant to print out initMemory before totalMemory :-)
+System.out.printf("consuming memory: i: %d, initial: %d, total: %d,
delta: %d%n",
+i, totalMemory, initMemory, totalMemory - initMemory);
**i, initMemory,
Hi Joe,
On Apr 27, 2015, at 5:32 PM, joe darcy wrote:
> The patch looks pretty good. A few questions / comments:
>
> The test ParseHexFloatingPoint.java didn't get the "(use -Dseed=X to set PRNG
> seed)" addition; was that intentional?
No, it was an oversight. Thanks for catching it. I though
Hi Brian,
The patch looks pretty good. A few questions / comments:
The test ParseHexFloatingPoint.java didn't get the "(use -Dseed=X to set
PRNG seed)" addition; was that intentional?
To save some space on the @summary line
Numerical tests for hexadecimal inputs to parseDouble, parseFloa
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,
He
Please review adding diagnostic output to identify an intermittent failure.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-lots-8078582/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8078582
Thanks, Roger
This discussion has been moved here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/033058.html
Please reply to the forgoing thread regarding this topic.
The request for review of a fix for
https://bugs.openjdk.java.net/browse/JDK-8078586 is withdrawn for the time
being.
Than
Note: This is a relabeling and extension of a patch originally addressed
towards https://bugs.openjdk.java.net/browse/JDK-8078586 in this discussion
thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/033037.html.
With that preamble, please review the revised code at your con
On Mon, Apr 27, 2015 at 3:22 PM, Stephen Colebourne
wrote:
> This is a request for an additional method on java.util.stream.Stream.
>
> Having written quite a bit of code in Java 8 now, one annoyance keeps
> on coming up, filtering and casting the stream.
>
> Currently, it is necessary to do this
Hi Daniel,
The set of affected tests is somewhat limited in that the real cause of
the timeout
is reading the timezone information and the extra code that it throws into
the mix due to -Xcomp. Also, the current sequence of tests may be
hiding some failures since the one-time initialization ha
On 27/04/2015 10:21 PM, David Holmes wrote:
On 27/04/2015 5:28 PM, Daniel Fuchs wrote:
Hi David,
On 4/27/15 3:21 AM, David Holmes wrote:
Hi Daniel,
On 25/04/2015 3:07 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch that tries to improve the locking
strategy in LogManager.
The patch p
Hi Roger,
Looks good to me. I'm surprised that only these tests are failing.
IIRC I also had to round up some time comparisons in tests when I
increased the resolution of the SystemClock - and I believe I rounded
them to only 1 second...
Anyway - if they fail we know what to do :-)
best regard
On 04/27/2015 05:23 PM, Paul Sandoz wrote:
On Apr 27, 2015, at 4:56 PM, Stephen Colebourne wrote:
Obviously, this is yet another possible workaround. But it is a
workaround.
I don't consider it "just a workaround" :-)
There really aren't that many rough edges with the set of
methods added
Fine by me.
Stephen
On 27 April 2015 at 19:50, Roger Riggs wrote:
> Please review a timing relaxation so tests do not fail on very slow hardware
> with more expensive runtime options. (-Xcomp)
>
> The change will also be backported to jdk 8.
>
> Issue:
>8078369: [testbug] java/time/tck/java/
Please review a timing relaxation so tests do not fail on very slow
hardware
with more expensive runtime options. (-Xcomp)
The change will also be backported to jdk 8.
Issue:
8078369: [testbug] java/time/tck/java/time/TCKOffsetTime[now] fails
on slow devices
Webrev:
http://cr.openjdk.
This seems like a good enhancement.
Stephen
On 27 April 2015 at 16:26, Peter Levart wrote:
> Hi,
>
> Please review the following improvement that caches default ZoneId object
> and makes the frequently executed ZoneId.systemDefault() method faster:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev
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 wrote:
> Hi again,
>
> Here's another optimization to be reviewed that has been discussed a while
> ago (just rebased from webrev
Hi everyone,
Could you please review my change for JDK-8029804
http://cr.openjdk.java.net/~prappo/8029804/webrev.00/
---
There is an issue where java.io.BufferedWriter.write(String s, int off, int len)
doesn't check requ
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 ZoneId.sys
Hi,
Please review the following improvement that caches default ZoneId
object and makes the frequently executed ZoneId.systemDefault() method
faster:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.04/
The patch is just a rebased version of webrev.03 + some comments
On Apr 27, 2015, at 4:56 PM, Stephen Colebourne wrote:
> Obviously, this is yet another possible workaround. But it is a
> workaround.
I don't consider it "just a workaround" :-)
> There really aren't that many rough edges with the set of
> methods added with lambdas, but this is definitely one
Obviously, this is yet another possible workaround. But it is a
workaround. There really aren't that many rough edges with the set of
methods added with lambdas, but this is definitely one. That Guava
handled it specially is another good indication.
BTW, I wait months before making this request to
Hi Stephen,
You can do this:
static Function> casting(Class c) { // bike shed for
clearer name
return o -> Stream.ofNullable(c.isInstance(o) ? c.cast(o) : null);
}
Object[] s = Stream.of(1, 2, "3", 4).toArray();
Stream.of(s).flatMap(casting(Integer.class)).
forEach(System.out::pri
This is a request for an additional method on java.util.stream.Stream.
Having written quite a bit of code in Java 8 now, one annoyance keeps
on coming up, filtering and casting the stream.
Currently, it is necessary to do this:
return input.stream()
.filter(Foo.class::isInstance)
On 27/04/2015 5:28 PM, Daniel Fuchs wrote:
Hi David,
On 4/27/15 3:21 AM, David Holmes wrote:
Hi Daniel,
On 25/04/2015 3:07 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch that tries to improve the locking
strategy in LogManager.
The patch proposes to use a Reantrant lock to deal with
Hi David,
On 4/27/15 3:21 AM, David Holmes wrote:
Hi Daniel,
On 25/04/2015 3:07 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch that tries to improve the locking
strategy in LogManager.
The patch proposes to use a Reantrant lock to deal with
configurations changes in reset() and readCo
26 matches
Mail list logo
