Hi
Please help review the change for #8042369
Issue: https://bugs.openjdk.java.net/browse/JDK-8042369
Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev
In jdk8 we had to duplicate dozen java.time classes in build.tools to build the
timezone data
for the new JSR310 timezone data
Hello,
On 04/05/2014 20:41, Joe Darcy wrote:
Hello,
On 5/4/2014 9:56 AM, solo-java-core-l...@goeswhere.com wrote:
Hey,
Could someone please help me understand what changes have happened in
rounding in DecimalFormat in Java 8?
new DecimalFormat(0.00).format(1.035) is 1.04 on Java 7, and 1.03
Hello,
Can you maybe point to the commit or Bug Number for this? The outcome of
this correctness fit is pretty unfortunate (at least for the Number in
question).
I could imagine a new RoundingMode could help for users which insist on
convieningly shoot themself in the foot.
Greetings
Bernd
On 05/05/2014 09:59, Bernd wrote:
Hello,
Can you maybe point to the commit or Bug Number for this? The outcome of
this correctness fit is pretty unfortunate (at least for the Number in
question).
Initial bug Number in JDK7 is JDK-7131459:
https://bugs.openjdk.java.net/browse/JDK-7131459
On May 2, 2014, at 9:22 PM, Mike Duigou mike.dui...@oracle.com wrote:
Thanks Martin and Martin;
I have corrected this along with some additional documentation updates:
http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/
+1.
Paul.
On May 3, 2014, at 6:55 PM, Joe Darcy joe.da...@oracle.com wrote:
Hi Brian,
I think the parsePrimes method would be better with a different name since no
parsing is occurring anymore.
Yes, and there is no need for the try block.
(The use of BitSet.stream() also reminds me we can
On 03/05/2014 01:04, Bernd Eckenfels wrote:
Hello,
back in 2011 there was a discussion about the new changed behavior of
FilterOutputStream (and BufferedOutputStream) in regards to not anymore
swalloging IOExceptions from flush() on this list (thats where I got
the subject from).
This was
Thanks Alan,
I just want to add that I think the IAE is quite in a unfortunate location
when it is caused by TWR. Especially for that usecase silently ignoring the
add is more robust.
If you look at Stackoverflow or Google there ard already other People
confused by it, it happens all over the
Am 02.05.2014 18:13, schrieb Joe Darcy:
On 5/2/2014 9:10 AM, Ulf Zibis wrote:
Am 01.05.2014 02:20, schrieb Joe Darcy:
If from an API perspective the new code is preferable, I would say that should take precedence
over an at most marginal performance degradation.
I guess you meant: ...
Hi Stuart,
great proposal. You can count on me when it comes to testing on exotic
platforms like for example AIX:)
Regards,
Volker
On Thu, May 1, 2014 at 2:08 AM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi all,
Here's a draft JEP for stabilizing the core libraries regression test suite,
Hi,
https://bugs.openjdk.java.net/browse/JDK-8042355
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/
This is an optimization to ensure that sorted() in sequential pipelines does
not aggressively push all sorted elements downstream if the pipeline is known
On 05/05/2014 11:31 AM, Alan Bateman wrote:
On 03/05/2014 01:04, Bernd Eckenfels wrote:
Hello,
back in 2011 there was a discussion about the new changed behavior of
FilterOutputStream (and BufferedOutputStream) in regards to not anymore
swalloging IOExceptions from flush() on this list (thats
On 05/05/2014 15:40, Peter Levart wrote:
Hi Alan,
There has been a discussion about a year ago on this list:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015947.html
Yes, I remember this and also reviewed it for Joe. My point about it not
coming up before was in the
Please review for JDK 9, editorial corrections and cleanup for java.time
classes.
The grammar has been improved and some redundant @throws NPE clauses
removed.
Javadoc links have been corrected. Original patch from Stephen Colebourne,
some additions and corrections by me.
webrev:
Looks good to me.
On May 5 2014, at 06:16 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8042355
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/
This is an optimization to ensure that sorted() in sequential
Hello!
This is a friendly reminder.
Could a Reviewer please review/approve this fix?
The problem is that a BitSet can have bit # MAX_VALUE set, but trying to
convert it to String throws an exception.
Sincerely yours,
Ivan
On 22.04.2014 16:13, Ivan Gerasimov wrote:
Hello!
If a BitSet has
The fix looks good though I wonder if the conditional checks can be optimized a
bit.
I am concerned that the suggested iteration method provided in the nextSetBit()
javadoc induces the same failure we just corrected. Perhaps we should revise
that advice?
Mike
On May 5 2014, at 09:56 , Ivan
Thank you Mike!
On 05.05.2014 21:37, Mike Duigou wrote:
The fix looks good though I wonder if the conditional checks can be optimized a
bit.
Hm. I don't see lots of room for optimization here without revising
nexSetBit() and nextClearBit() implementation.
The first check at 1190 is
On May 5 2014, at 11:54 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Thank you Mike!
On 05.05.2014 21:37, Mike Duigou wrote:
The fix looks good though I wonder if the conditional checks can be
optimized a bit.
Hm. I don't see lots of room for optimization here without revising
Joe / Paul,
Thanks for the comments. This an aggregate response to your two messages. An
updated version of the patch is here:
http://cr.openjdk.java.net/~bpb/8026236/webrev.03/
I believe that it addresses all the points of concern aside from testing
Mersenne primes.
Please see more comments
Hi, Please have codereview for
8042243: Map shared archive to preallocated static address
webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/
bug: https://bugs.openjdk.java.net/browse/JDK-8042243
Summary: Mapping shared archive (jsa) some time fail due to ASLR
(Address space layout
Hi Yumin,
For something that only addresses one platform this adds a lot of
platform specific code to a bunch of shared files. Are there plans to
extend this to other platforms? Otherwise can we make this more platform
agnostic? Perhaps move the os specific code to the os class? Seems the
David,
Thanks for the review.
On 5/5/2014 7:59 PM, David Holmes wrote:
Hi Yumin,
For something that only addresses one platform this adds a lot of
platform specific code to a bunch of shared files. Are there plans to
extend this to other platforms? Otherwise can we make this more
platform
23 matches
Mail list logo
