Re: ThreadLocalRandom clinit troubles

On 06/24/2014 06:01 PM, Martin Buchholz wrote: On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart > wrote: I would rather use SecureRandom.generateSeed() instance method instead of SecureRandom.nextBytes(). Why? Because every SecureRandom instance has

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

New webrev-05 with Kumar's comments except for the "C'ish" style. Explained below. http://cr.openjdk.java.net/~ntoda/8042469/webrev-05/ 105 : DONE 146: DONE 168: DONE 106: Your suggestion was the way I had originally coded it for Linux. However on Windows/Cygwin, the code will not

Re: RFR: 8048021: Remove @version tag in jaxp repo

Thanks for reviewing, glad you find out where it is. Cheers, Henry On 06/24/2014 01:56 PM, huizhe wang wrote: Looks good. Thanks for the extra work! I think your webrev is here: http://cr.openjdk.java.net/~henryjen/jdk9/8048021/0/webrev/ Cheers, Joe On 6/24/2014 1:00 PM, Henry Jen wrote: Hi

Re: RFR: 8048021: Remove @version tag in jaxp repo

Looks good. Thanks for the extra work! I think your webrev is here: http://cr.openjdk.java.net/~henryjen/jdk9/8048021/0/webrev/ Cheers, Joe On 6/24/2014 1:00 PM, Henry Jen wrote: Hi, As a follow up task, please review the trivial webrev to remove @version tags used with SCM, which is likel

RE: Zombie FileHandler locks can exhaust all available log file locks.

Daniel, I agree with you. I think you have it all covered. Thanks for working on this! Jason > Date: Tue, 24 Jun 2014 19:37:24 +0200 > From: daniel.fu...@oracle.com > To: jason_mehr...@hotmail.com; alan.bate...@oracle.com; > core-libs-dev@openjdk.j

RFR: 8048021: Remove @version tag in jaxp repo

Hi, As a follow up task, please review the trivial webrev to remove @version tags used with SCM, which is likely to be meaningless to javadoc readers. In this webrev, we only remove @version with $Id or $Revision for .jave or package.html cause appearance to javadoc. We keep those in .prope

RFR: 8048020 - Regression on java.util.logging.FileHandler

Hi, Please find below a patch [1] for [2]: 8048020 - Regression on java.util.logging.FileHandler This corresponds to the problem that was discussed on this list in the following email thread: "Zombie FileHandler locks can exhaust all available log file locks." http://mail.openjdk.java.net/pipe

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

On Jun 24 2014, at 01:18 , Paul Sandoz wrote: >> Additionally the javadoc is updated to inform users that a >> ClassCastException may result if the proposed replacement is unacceptable. >> > > No users will see the JavaDoc on Collections.CheckedList since it is package > private, plus i think

Re: A question about Depth of container annotations

Hello, The behavior you're interested in is defined in the AnnotatedElement specification: http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElement.html In brief, none of the methods in AnnotatedElement look through more than one level of containment. (Likewise, when writi

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

On Jun 24 2014, at 01:46 , Chris Hegarty wrote: > Looks good to me Mike. > > I agree with Paul’s comment that the javadoc change will never be seen in the > public docs, but I still think it is a reasonable addition for future > maintainers. > > Trivially, you should probably add @SuppressWa

Re: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods

On 06/24/2014 10:43 AM, Paul Benedict wrote: Will there be another ticket to update the section (9.6.4.7.) in JLS 9? JDK-8047159: 9.6.4.7: Allow @SafeVarargs on private methods https://bugs.openjdk.java.net/browse/JDK-8047159 Cheers, -Joe Cheers, Paul On Tue, Jun 24, 2014 at 12:

Re: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods

Will there be another ticket to update the section (9.6.4.7.) in JLS 9? Cheers, Paul On Tue, Jun 24, 2014 at 12:27 PM, Lance Andersen wrote: > +1 > On Jun 24, 2014, at 1:13 PM, Joe Darcy wrote: > > > Hello, > > > > Please review the libraries update portion of allowing @SafeVarargs on > priv

Re: Zombie FileHandler locks can exhaust all available log file locks.

Hi Jason, Thanks for the feedback! On 6/24/14 7:08 PM, Jason Mehrens wrote: Daniel, With regard to JDK-4420020, in the original webrev Jim was incorrectly using java.io.File.canWrite() but that webrev was replaced by the current version. The NIO.2 code performs the effective access checks c

Re: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods

+1 On Jun 24, 2014, at 1:13 PM, Joe Darcy wrote: > Hello, > > Please review the libraries update portion of allowing @SafeVarargs on > private instance methods: > >JDK-8048014: Update java.lang.SafeVararags for private methods > > The patch is > > diff -r 6c26f18d9bc0 src/share/classes/j

JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods

Hello, Please review the libraries update portion of allowing @SafeVarargs on private instance methods: JDK-8048014: Update java.lang.SafeVararags for private methods The patch is diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java --- a/src/share/classes/java/lang/SafeVara

RE: Zombie FileHandler locks can exhaust all available log file locks.

Daniel, With regard to JDK-4420020, in the original webrev Jim was incorrectly using java.io.File.canWrite() but that webrev was replaced by the current version. The NIO.2 code performs the effective access checks correctly. With regard to JDK-6244047 my concern was that checking the permissi

Re: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo

On 6/24/2014 12:19 AM, Alan Bateman wrote: On 24/06/2014 01:14, huizhe wang wrote: : One thing that concerns me a bit is that none of the .java files that I looked at have any comments to say what the test does. Is there anything that could be brought over from the original issue in JIRA

Re: Review request for 8047904: Runtime.loadLibrary throws SecurityException when security manager is installed

On 23/06/2014 21:23, Mandy Chung wrote: The loadLibrary implementation is missing to wrap the call to File.getCanonicalPath method with doPrivileged block. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/ I think this is okay too, one shouldn't require anymore than the

Re: Review request for 8047904: Runtime.loadLibrary throws SecurityException when security manager is installed

On Jun 23, 2014, at 10:23 PM, Mandy Chung wrote: > The loadLibrary implementation is missing to wrap the call > to File.getCanonicalPath method with doPrivileged block. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8047904/webrev.00/ > Looks ok to me. Paul.

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Looks good to me. Thanks, Fred On 24/06/2014 17:11, Coleen Phillimore wrote: On 6/24/14, 4:41 AM, Frederic Parain wrote: Hi Coleen, It seems that there's still a reference to JVM_GetClassLoader in file jdk/src/share/native/common/check_code.c. The code looks like dead code, but it would be

Re: RFR 6642881: Improve performance of Class.getClassLoader()

On 6/24/14, 4:41 AM, Frederic Parain wrote: Hi Coleen, It seems that there's still a reference to JVM_GetClassLoader in file jdk/src/share/native/common/check_code.c. The code looks like dead code, but it would be nice to clean it up. I removed this code. There are no other instances of the

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Mikael, see below. On 6/24/14, 9:48 AM, Mikael Gerdin wrote: On Tuesday 24 June 2014 08.51.18 Coleen Phillimore wrote: Hi Peter, On 6/24/14, 4:23 AM, Peter Levart wrote: On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to

Re: ThreadLocalRandom clinit troubles

Hi Martin, On 06/22/2014 07:12 PM, Martin Buchholz wrote: We know that loading the networking machinery is problematic. On Linux we would be content to hard-code a read from /dev/urandom, which is safer and strictly more random than the existing network hardware determination, but y'all will re

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

On Jun 17, 2014, at 6:52 PM, Joel Borggrén-Franck wrote: > Hi, > > Can I get a review for this fix and javadoc clarification for > https://bugs.openjdk.java.net/browse/JDK-8044629 > > The problem is with potentially annotated receiver parameters, they only > exist for inner class constructo

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Fred, Thank you for finding this. Yes, I meant to clean this up with the bug to remove JVM_GetClassLoader but I should remove this with this change instead, since the other change will be in hotspot only. Yes, it's dead code. Thanks! Coleen On 6/24/14, 4:41 AM, Frederic Parain wrote: Hi C

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Hi Peter, On 6/24/14, 4:23 AM, Peter Levart wrote: On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field. In t

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

Neil, Some nits: TestSpecialArgs.java: extra space 105 for ( String line : tr.testOutput) { This is very C'ish, I suggest. -106 int index; -107 if ((index = line.indexOf(envVarPidString)) >= 0) { +106 int index = line.indexOf(envVarPidStri

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

Looks good to me Mike. I agree with Paul’s comment that the javadoc change will never be seen in the public docs, but I still think it is a reasonable addition for future maintainers. Trivially, you should probably add @SuppressWarnings("unchecked”) to typeCheck(Object). -Chris. On 24 Jun 20

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Hi Coleen, It seems that there's still a reference to JVM_GetClassLoader in file jdk/src/share/native/common/check_code.c. The code looks like dead code, but it would be nice to clean it up. Thanks, Fred On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code

Re: RFR 6642881: Improve performance of Class.getClassLoader()

On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field. In the spec, AccessibleObject.setAccessible() may throw S

A question about Depth of container annotations

Hi All, I have a question about repeated annotation depth. If this is not the proper mailing list group, please tell me where I should send it to. My question will be about the depth of container annotations. For instance, assume there are 3 annotations. - RepeatedAnn - ContainerAnn - ContainerCo

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

On Jun 24, 2014, at 2:42 AM, Mike Duigou wrote: > Hello all; > > This changeset corrects a reported problem with the lists returned by > Collections.checkedList(). Since Java 8 the replaceAll() method on checked > lists has erroneously allowed the operator providing replacements to provide >

Re: RFR 8035490: move xml jaxp unit tests in bugxxx dir into jaxp repo

On 24/06/2014 01:14, huizhe wang wrote: : One thing that concerns me a bit is that none of the .java files that I looked at have any comments to say what the test does. Is there anything that could be brought over from the original issue in JIRA to explain what each of these tests is about?

Re: RFR 6642881: Improve performance of Class.getClassLoader()

On 24/06/2014 00:45, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field. In the spec, AccessibleObject.setAccessible() may throw Secu