Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Chris Hegarty
Alan, I checked the httpsever and sctp changes. All look good to me. -Chris. On 10/06/2013 09:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, I'd like to have another attempt at adding the annotation to a number of JDK specific APIs that are

Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread Mandy Chung
JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9.

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Vincent Ryan
The JAAS and JGSS changes look fine too. On 7 Oct 2013, at 09:23, Chris Hegarty wrote: Alan, I checked the httpsever and sctp changes. All look good to me. -Chris. On 10/06/2013 09:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,

Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread Remi Forax
On 10/07/2013 10:24 AM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we

Re: RFR: 8025968: Integrate test improvements made in lambda repo

2013-10-07 Thread Paul Sandoz
On Oct 5, 2013, at 1:13 AM, Henry Jen henry@oracle.com wrote: Hi, Please review a port from lambda repo to tl, it contains a refactoring of OpTestCase and a small addition to fill test gap. http://cr.openjdk.java.net/~henryjen/tl/8025968/0/webrev/ Looks good. Paul.

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Daniel Fuchs
Hi Alan, The com.sun.management changes look good. -- daniel On 10/6/13 10:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, I'd like to have another attempt at adding the annotation to a number of JDK specific APIs that are long standing

hg: jdk8/tl/jdk: 8025983: Typo in Javadoc of Files.isRegularFile()

2013-10-07 Thread alan . bateman
Changeset: 0ac9dc315071 Author:alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java !

Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread Alan Bateman
On 07/10/2013 09:24, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Alan Bateman
On 07/10/2013 11:31, Mandy Chung wrote: : For the review then the intention is that @jdk.Exported be added to the package-info and all public/protected types in these APIs. The only exceptions are two cases where I've added @jdk.Exported(false), specifically: -

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread Peter Levart
More test data... Running the previously mentioned measurement (allocating direct buffers randomly sized between 256KB and 1MB for 60 seconds) with a single allocating tread that presents allocation pressure which is still acceptable for original code (two threads are already too much an lead

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Sean Mullan
7 classes in com.sun.security.auth have been deprecated for several major releases now. Should they still have this annotation? --Sean On 10/06/2013 04:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, I'd like to have another attempt at adding

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Alan Bateman
On 07/10/2013 13:26, Sean Mullan wrote: 7 classes in com.sun.security.auth have been deprecated for several major releases now. Should they still have this annotation? --Sean I know but aren't they still exported and supported? DialogCallbackHandler is the only one with its name on a bullet.

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Sean Mullan
On 10/07/2013 08:28 AM, Alan Bateman wrote: On 07/10/2013 13:26, Sean Mullan wrote: 7 classes in com.sun.security.auth have been deprecated for several major releases now. Should they still have this annotation? --Sean I know but aren't they still exported and supported? They have all had

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread Aleksey Shipilev
Hi Peter, On 10/07/2013 02:56 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ The 1 hour run of this on my 1x2x2 i5, directMem=16m, original DirectByteBufferTest yields no failures! Oh my. Good job! Comments on the code: Bits.java: -

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Alan Bateman
On 07/10/2013 13:36, Sean Mullan wrote: We have only started removing some deprecated things in JDK, so it just was never thought about until now. Marking these as supported going forward strikes me as a bit strange, since we don't really want anyone using these anymore. As a guide, I think

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Sean Mullan
On 10/07/2013 08:58 AM, Alan Bateman wrote: On 07/10/2013 13:36, Sean Mullan wrote: We have only started removing some deprecated things in JDK, so it just was never thought about until now. Marking these as supported going forward strikes me as a bit strange, since we don't really want anyone

Re: SplittableRandom update

2013-10-07 Thread Paul Sandoz
While having one last look at this Doug and I found some oops how the heck did that happen miscommits with the mix64/mix32/nextGamma methods that contained test code for measuring the impact of shifts: For corrections see:

Re: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds

2013-10-07 Thread Alan Bateman
On 04/10/2013 16:10, Rob McKenna wrote: Hi Pavel, Thanks for sorting this out. I'm not a reviewer but hopefully Alan will have a look when he gets a chance. Based on the bug description this looks good to me though. -Rob I looked over the weekend and it's mostly okay (thanks Pavel for

Re: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds

2013-10-07 Thread Rob McKenna
Yep. -Rob On 07/10/13 14:24, Alan Bateman wrote: On 04/10/2013 16:10, Rob McKenna wrote: Hi Pavel, Thanks for sorting this out. I'm not a reviewer but hopefully Alan will have a look when he gets a chance. Based on the bug description this looks good to me though. -Rob I looked

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread Alan Bateman
On 06/10/2013 23:56, Peter Levart wrote: : It's not so much about helping to achieve better throughput (as I noted deallocating can not be effectively parallelized) but to overcome the latency of waking-up the ReferenceHandler thread. Here's my attempt at doing this:

Debug builds

2013-10-07 Thread cowwoc
Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread Peter Levart
On 10/07/2013 02:43 PM, Aleksey Shipilev wrote: Hi Peter, On 10/07/2013 02:56 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ The 1 hour run of this on my 1x2x2 i5, directMem=16m, original DirectByteBufferTest yields no failures! Oh my. Good

Re: RFR 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds

2013-10-07 Thread Pavel Punegov
Hi Alan, On Monday 07 October 2013 14:24:40 you wrote: On 04/10/2013 16:10, Rob McKenna wrote: Hi Pavel, Thanks for sorting this out. I'm not a reviewer but hopefully Alan will have a look when he gets a chance. Based on the bug description this looks good to me though. -Rob

Re: Debug builds

2013-10-07 Thread Steven Schlansker
On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org wrote: Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like

Re: Debug builds

2013-10-07 Thread cowwoc
On 07/10/2013 1:35 PM, Steven Schlansker wrote: On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org wrote: Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but

Re: Code Review Request for 8025967 addition of -Werror broke the old build

2013-10-07 Thread Valerie (Yu-Ching) Peng
Thanks Vinnie for the review~ Forwarding this request to core-libs-dev per Sean's suggestion. Changes are for getting rid of compiler warnings in order for JCE provider build (still using the old build process) to complete successfully - either add the annotation to suppress rawtype warnings

hg: jdk8/tl/jdk: 8025968: Integrate test improvements made in lambda repo

2013-10-07 Thread henry . jen
Changeset: f0ad3e2918b4 Author:henryjen Date: 2013-10-07 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ad3e2918b4 8025968: Integrate test improvements made in lambda repo Reviewed-by: psandoz ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java !

Re: JDK 8 RFR 8016252: More defensive HashSet.readObject

2013-10-07 Thread Alan Bateman
On 07/10/2013 18:40, Brian Burkhalter wrote: : I have posted an updated webrev here: http://cr.openjdk.java.net/~bpb/8016252.2/ I don't know whether it is the correct way to go, but this version attempts to use the capacity, load factor, and size as read in, insofar as they appear

Re: JDK 8 RFR 8016252: More defensive HashSet.readObject

2013-10-07 Thread Brian Burkhalter
On Oct 7, 2013, at 1:31 PM, Alan Bateman wrote: I'm not so sure about capacity, a simple check if it is negative should be sufficient. The idea was to try to use the value if it appears reasonable, which is assured by the clamping. For size then I don't think the Math.max has any real

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread Peter Levart
On 10/07/2013 04:10 PM, Alan Bateman wrote: On 06/10/2013 23:56, Peter Levart wrote: : It's not so much about helping to achieve better throughput (as I noted deallocating can not be effectively parallelized) but to overcome the latency of waking-up the ReferenceHandler thread. Here's my

Re: JDK 8 RFR 8016252: More defensive HashSet.readObject

2013-10-07 Thread Brian Burkhalter
On Oct 7, 2013, at 1:31 PM, Alan Bateman wrote: For size then I don't think the Math.max has any real effect because the loop don't do anything if size is negative You could just throw IllegalObjectException if it is negative (as per the first patch) if you really wanted to. On second

Re: JDK 8 RFR 8016252: More defensive HashSet.readObject

2013-10-07 Thread Brian Burkhalter
On Oct 7, 2013, at 1:43 PM, Brian Burkhalter wrote: On second thought an exception really should be thrown on negative size; will update. http://cr.openjdk.java.net/~bpb/8016252.2/ updated including a not-very-exciting and perhaps unnecessary test. Brian

Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE

2013-10-07 Thread Mike Duigou
On Oct 4 2013, at 13:58 , Brian Burkhalter wrote: On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote: On 03/10/2013 16:10, Brian Burkhalter wrote: Please review and comment at your convenience. Issue:

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

2013-10-07 Thread Joseph Darcy
Hello, I skimmed the patch and it looked fine. More generally, we want every package and top-level class in the com.sun.* namespace to be either explicitly exported or not. Cheers, -Joe On 10/6/2013 1:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to

RFR: 8026009: Changes for 8025968 break all stream tests

2013-10-07 Thread Henry Jen
Hi, May I have a quick review on this left-out change to fix broken test? Apology for the inconvenience. http://cr.openjdk.java.net/~henryjen/tl/8026009/0/webrev/ Following is all it is, diff --git a/test/java/util/stream/bootlib/java/util/stream/OpTestCase.java

Re: RFR: 8026009: Changes for 8025968 break all stream tests

2013-10-07 Thread Mike Duigou
Looks good to me but I haven't completed a full build/test with this change (yet). Mike On Oct 7 2013, at 14:56 , Henry Jen wrote: Hi, May I have a quick review on this left-out change to fix broken test? Apology for the inconvenience.

Re: RFC 6910473: BigInteger negative bit length, value range, and future prospects

2013-10-07 Thread Joseph Darcy
Without comments on the contents of the patch, a change in documented behavior would require a ccc request. Cheers, -Joe On 10/3/2013 5:58 PM, Brian Burkhalter wrote: I have reviewed this proposed change a couple of times in its current form and it looks good to me. It would be good to see

Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE

2013-10-07 Thread Brian Burkhalter
On Oct 7, 2013, at 2:47 PM, Mike Duigou wrote: An updated webrev which I hope adequately addresses the expressed concerns may be found at: http://cr.openjdk.java.net/~bpb/7179567.2/ Looks good to me. Does the addition of If {@code codesource} is {@code null} the returned {@code

Re: RFC 6910473: BigInteger negative bit length, value range, and future prospects

2013-10-07 Thread Brian Burkhalter
I would expect as much, but that's an exercise I'd prefer to avoid at this time if the content does not appear likely to be acceptable. Thanks, Brian On Oct 7, 2013, at 3:26 PM, Joseph Darcy wrote: Without comments on the contents of the patch, a change in documented behavior would require

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

2013-10-07 Thread Brian Burkhalter
Resuming this discussion … Thanks for the previous comments. My feeling at this point is to do one of two things: A) defer to something after JDK 8, or B) on EAI_AGAIN do not retry but set the cause of the UAE to new SomeException(gai_strerror(error)) where SomeException could be for example

hg: jdk8/tl/langtools: 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer

2013-10-07 Thread joe . darcy
Changeset: 4dd7ffbf01fb Author:darcy Date: 2013-10-07 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dd7ffbf01fb 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Reviewed-by: jjg !

hg: jdk8/tl/jdk: 8026009: Changes for 8025968 break all stream tests

2013-10-07 Thread henry . jen
Changeset: 0cffe1dab0bf Author:henryjen Date: 2013-10-07 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cffe1dab0bf 8026009: Changes for 8025968 break all stream tests Reviewed-by: mduigou ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java

Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread Mandy Chung
On 10/7/2013 11:34 AM, Christian Thalinger wrote: Unfortunate but I understand. It might be a good idea to add a getCallerClass(-1) call to the test case. The VM should throw an exception if JVM_GetCallerClass is called by any method other than Reflection.getCallerClass(). It's a good idea

Re: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair

2013-10-07 Thread Mike Duigou
On Oct 3 2013, at 22:15 , David Holmes wrote: On 4/10/2013 1:35 PM, Mike Duigou wrote: Hello all; This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. It isn't at all clear to me what specification you are using to define

hg: jdk8/tl/jdk: 6956398: make ephemeral DH key match the length of the certificate key

2013-10-07 Thread xuelei . fan
Changeset: 0d5f4f1782e8 Author:xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java +

Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE

2013-10-07 Thread David Holmes
Hi Brian, Aside: I'm confused about the relationship of this bug and JDK-6445180 - are they not duplicates? Seems to me this one should have been closed as a dup when it was reported. On 5/10/2013 6:58 AM, Brian Burkhalter wrote: On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote: On Oct

Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread David Holmes
Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just

Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

2013-10-07 Thread Mandy Chung
On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

2013-10-07 Thread David Holmes
On 8/10/2013 6:36 AM, Peter Levart wrote: Somewhere I read that the resolution of Thread.sleep() is not 1 ms, but much more. In that case Thread.sleep(1) sleeps much more. That must have been some time ago or on some other platform, because if I run this on current JDK8/Linux: for