Hi,
Please review the following which fixes an embarrassing bug in
DoubleStream.count:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8031187-DoubleStream-count/webrev/
I included a test CountLargeTest that counts up to Integer.MAX_VALUE + 1. On my
mac book this takes about 27s to run from
Thanks!
On 1/3/2014 2:04 PM, Lance @ Oracle wrote:
Looks ok joe
http://oracle.com/us/design/oracle-email-sig-198324.gifLance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
tel:+1.781.442.2037
Oracle Java Engineering
1 Network Drive x-apple-data-detectors://34/0
Burlington,
On 6 Jan 2014, at 17:25, Martin Buchholz marti...@google.com wrote:
On Mon, Jan 6, 2014 at 9:19 AM, Mike Duigou mike.dui...@oracle.com wrote:
If you navigate through
http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html
it shows just the relevant diffs. It
Please review this minor specification correction to the
java.time.Duration.toDays() and
toHours() methods. Only the javadoc is corrected, no code or tests are
affected.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/
Thanks, Roger
JDK-8031103
Looks good Paul; if not 8 GA, than backported to an early 8 update.
Cheers,
-Joe
On 01/06/2014 02:05 AM, Paul Sandoz wrote:
Hi,
Please review the following which fixes an embarrassing bug in
DoubleStream.count:
looks fine Roger
On Jan 6, 2014, at 2:09 PM, roger riggs wrote:
Please review this minor specification correction to the
java.time.Duration.toDays() and
toHours() methods. Only the javadoc is corrected, no code or tests are
affected.
Webrev:
On 6 Jan 2014, at 17:05, Martin Buchholz marti...@google.com wrote:
On Mon, Jan 6, 2014 at 8:47 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Part 2...
JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify their
default implementation using @implSpec
Changeset: d77a1c9fd5b8
Author:dfuchs
Date: 2013-12-22 11:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8
8030850: Setting .level=FINEST in logging configuration file doesn't work
Summary: setLevel(INFO) was called too early on root logger, causing the value
If you navigate through
http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html
it shows just the relevant diffs. It appears that the specdiff was generated
without an explicit --includes option which results in all the extra chaff.
Mike
On Jan 6 2014, at 09:05 ,
Part 2...
JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify
their default implementation using @implSpec
http://cr.openjdk.java.net/~chegar/8031142/webrev/
http://cr.openjdk.java.net/~chegar/8031142/specdiff/
-Chris.
On 06/01/14 15:37, Mike Duigou wrote:
Coming in
Coming in late but this looks like a very good change to me as well.
Mike
On Jan 2 2014, at 23:06 , Chris Hegarty chris.hega...@oracle.com wrote:
On 3 Jan 2014, at 02:14, Martin Buchholz marti...@google.com wrote:
OK, as you wish - this change is clear progress!
Thanks Martin.
I
The test sets a security manager to ensure that appropriate permission
checks are performed. It expects to be denied reflective access to a
private field in a different package. Access, to this field, is granted
if the code has RuntimePermission accessDeclaredMembers. This
permission is not
On 6 Jan 2014, at 18:11, Chris Hegarty chris.hega...@oracle.com wrote:
On 6 Jan 2014, at 17:05, Martin Buchholz marti...@google.com wrote:
……..
In a sane language, the AbstractFoo classes would be traits - they should
never contribute to the *specification* of a concrete class, only to
Hello,
Please review the simple change to fix JDK-8027063
SecurityManger.getClassContext returns a raw type, which changes a
signature of a protected method in SecurityManger to remove a use of raw
types in the core libraries:
--- a/src/share/classes/java/lang/SecurityManager.javaMon
+1
On Jan 6, 2014, at 3:53 PM, Joe Darcy wrote:
Hello,
Please review the simple change to fix JDK-8027063
SecurityManger.getClassContext returns a raw type, which changes a signature
of a protected method in SecurityManger to remove a use of raw types in the
core libraries:
---
Hello,
Please review the patch below to add a @SuppressWarning(serial) to
java.lang.Enum to resolve a lint warning in the core libraries.
Thanks,
-Joe
--- a/src/share/classes/java/lang/Enum.javaMon Jan 06 11:48:32 2014
-0800
+++ b/src/share/classes/java/lang/Enum.javaMon Jan 06
Entirely reasonable. Approved.
Mike
On Jan 6 2014, at 13:41 , Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the patch below to add a @SuppressWarning(serial) to
java.lang.Enum to resolve a lint warning in the core libraries.
Thanks,
-Joe
---
+1
On Jan 6, 2014, at 4:41 PM, Joe Darcy wrote:
Hello,
Please review the patch below to add a @SuppressWarning(serial) to
java.lang.Enum to resolve a lint warning in the core libraries.
Thanks,
-Joe
--- a/src/share/classes/java/lang/Enum.javaMon Jan 06 11:48:32 2014 -0800
+++
Hi All,
Please review the simple fix for JNI pending exceptions in
FileSystemPreferences.c. Thanks!
Bug: https://bugs.openjdk.java.net/browse/JDK-8028726
Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/
-Dan
Dan,
Looks OK, but line 914 which you did not change, notice the comments not sure
if that is common in this code but seemed a bit off to me:
914 //// If at first, you don't succeed...
On Jan 6, 2014, at 5:29 PM, Dan Xu wrote:
Hi All,
Please review the simple fix for JNI
Hi Lance,
Thanks for your review.
My understanding towards the for loop in lockFile() of
FileSystemPreferences.java is that it retries if anything fails. So I
don't touch L914 to keep its old logic un-changed. Please let me know if
you have some good suggestions. Thanks!
-Dan
On
Back from vacation ...
On 20/12/2013 4:49 PM, David Holmes wrote:
On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote:
Hi David Thanks for your comments, the unguarded part(clean and enqueue)
in the Reference Handler thread does not seem to create any new objects,
so it is the
Sure David will give that a try, we have so far attempted to
1. Print state data(as per the test creator peter.levart's inputs),
2. Use UEH(uncaught exception handler per Mandy's inputs)
--
Thanks
kalyan
On 1/6/14 4:40 PM, David Holmes wrote:
Back from vacation ...
On 20/12/2013 4:49 PM,
Changeset: 014c04fd7460
Author:ascarpino
Date: 2013-12-04 17:37 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/014c04fd7460
8029550: javadoc since tag for recent Hashtable updates
Reviewed-by: mullan
! src/share/classes/java/security/Provider.java
Hello,
many real business applications make intensive use of the collections api. I
have spend some time and tried to improve it a bit:
I've added a shared empty array instances to java.util.Arrays and use
Arrays.EMPTY_OBJECT_ARRAY where appropriate in collection classes and reduce
use of new
Changeset: 6deabb82f72b
Author:ascarpino
Date: 2013-12-04 10:59 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6deabb82f72b
8027218: TEST_BUG: sun/security/pkcs11/ec tests fail because of ever-changing
key size restrictions
Reviewed-by: vinnie
!
Hi,
I digged through the object serialization code and found some lines that could
be optimized to reduce the number of calls to System.arraycopy() and temporary
object allocations especially during string (de)serialization.
In short sentences the changes are:
ObjectInputStream:
- skip
Looks fine to me.
Thanks,
Xuelei
On 1/7/2014 4:53 AM, Joe Darcy wrote:
Hello,
Please review the simple change to fix JDK-8027063
SecurityManger.getClassContext returns a raw type, which changes a
signature of a protected method in SecurityManger to remove a use of raw
types in the core
Hi All
Please help to review the code change for JDK-7027502.
http://cr.openjdk.java.net/~tyan/JDK-7027502/
Description:
This test was failed in JPRT test but recently we test with same
binaries run, it doesn't fail any more. The intention for this code
change is bringing this test back to
Hi Tristan,
On 7/01/2014 4:43 PM, Tristan Yan wrote:
Hi All
Please help to review the code change for JDK-7027502.
http://cr.openjdk.java.net/~tyan/JDK-7027502/
Description:
This test was failed in JPRT test but recently we test with same
binaries run, it doesn't fail any more. The intention
30 matches
Mail list logo
