Re: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

Daniel, I have added more tests and fixed a few issues http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.02/ I also created a test case similar to yours. This patch applies on top of: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.02/ for JDK-8156680: jdeps

Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or

RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi. Reviving this work from a few months back. Please review the following changes to move jdk.Version to jdk.lang.Runtime.Version. Bug 8144062: Move jdk.Version to java.lang.Runtime.Version https://bugs.openjdk.java.net/browse/JDK-8144062 webrev

Re: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag

On 5/13/16 1:24 PM, Alan Bateman wrote: On 13/05/2016 19:49, Xueming Shen wrote: something like this? http://cr.openjdk.java.net/~sherman/8147588/webrev/ Along these lines, yes. Would it be cleaner if ZipFile_openAndDelete were rename to ZipFile_open and used ZFILE_Open in libzip instead

Re: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag

On 13/05/2016 19:49, Xueming Shen wrote: something like this? http://cr.openjdk.java.net/~sherman/8147588/webrev/ Along these lines, yes. Would it be cleaner if ZipFile_openAndDelete were rename to ZipFile_open and used ZFILE_Open in libzip instead of winFileHandleOpen in libjava? Also

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

On 13 May 2016, at 19:04, Brian Burkhalter wrote: > Correction: wrong link provided below: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ Looks good to me Brian. -Chris. > Sorry for the confusion. > > Brian > > On May 13, 2016, at 10:42 AM, Brian

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hi Roger, On May 13, 2016, at 11:44 AM, Roger Riggs wrote: > Looks fine. Thanks for digging through all the cases. Thanks & you’re welcome. > The @see indenting is ok, but not really a thing. White space is should not > be used/relied upon for formatting. The

Re: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag

On 5/13/16 3:27 AM, Alan Bateman wrote: On 12/05/2016 20:16, Xueming Shen wrote: Hi, Please help review the proposed change for #8147588 issue: https://bugs.openjdk.java.net/browse/JDK-8147588 webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev This is a regression on Windows platform

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hi Brian, Looks fine. Thanks for digging through all the cases. The @see indenting is ok, but not really a thing. White space is should not be used/relied upon for formatting. Roger On 5/13/2016 2:34 PM, Brian Burkhalter wrote: Hi Pavel, On May 13, 2016, at 11:25 AM, Pavel Rappo

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hi Pavel, On May 13, 2016, at 11:25 AM, Pavel Rappo wrote: > This looks good! Good good! Thanks! > > Could you please fix this tiny typo in-place? > > 145 * @throws IOException if

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Brian, This looks good! Could you please fix this tiny typo in-place? 145 * @throws IOException if the pipe is 146 * broken},

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Correction: wrong link provided below: http://cr.openjdk.java.net/~bpb/8130679/webrev.02/ Sorry for the confusion. Brian On May 13, 2016, at 10:42 AM, Brian Burkhalter wrote: > I have a third version of the patch here: > >

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hello, I have a third version of the patch here: http://cr.openjdk.java.net/~bpb/8130679/webrev.00/ This one I believe addresses all the inconsistencies including the one in https://bugs.openjdk.java.net/browse/JDK-8029804 at the expense of a slight weakening of the specification of the

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

> On May 12, 2016, at 5:58 PM, David Holmes wrote: >> >> With all of the inherited methods @hidden, it looks like that section >> is left out altogether. > > Okay, so I have to say @hidden seems to me to be seriously flawed! If a class > has a method that can be

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

> On May 12, 2016, at 4:55 PM, Brent Christian > wrote: > > Update to the test, and additional comments: > > http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/ > +1 Mandy

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Good idea. Mandy > On May 13, 2016, at 12:10 AM, Peter Levart wrote: > > Hi Brent, > > > This looks good. It might also be a good idea to add a test that checks this > new implementation detail (the unsynchronized get) that new code will become > dependent upon, for

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Good point, Remi. I agree that it's redundant. Best regards, Vladimir Ivanov On 5/13/16 4:51 PM, Remi Forax wrote: Also instead of MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V",

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Also instead of MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", null, new String[] { "java/lang/Throwable" }); because the code is never read by

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

MethodHandle vamh = prepareForInvoker(MH_checkCallerClass); Object ok = bccInvoker.invokeExact(vamh, new Object[]{hostClass, bcc}); + assert Boolean.TRUE.equals(ok) : ok; What I meant is to convert the whole test (inside try-catch block) into an assert. +

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Note that there is a possible initialization circularity introduced by this patch, which I think is harmless because: - ThreadLocalRandom has just recently been enhanced to cope with such situations - CHM needs ThreadLocalRandom in put() for example, when new entry is being inserted, TLR

Re: RFR: 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag

On 12/05/2016 20:16, Xueming Shen wrote: Hi, Please help review the proposed change for #8147588 issue: https://bugs.openjdk.java.net/browse/JDK-8147588 webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev This is a regression on Windows platform triggered by the change for

RE: MethodHandle for array length

Hi, One addition, maybe add to issue: If this was added, jdk.dynalink module could use it, too - this was mentioned by Attila already: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java Uwe - Uwe Schindler

RE: MethodHandle for array length

Hi, OK, thanks for creating an issue! Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: Remi Forax [mailto:fo...@univ-mlv.fr] > Sent: Friday, May 13, 2016 10:37 AM > To: Uwe

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

> On 13 May 2016, at 10:56, shilpi.rast...@oracle.com wrote: > > Thanks Paul! > > Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ > +1 Paul.

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Thanks Paul! Please review http://cr.openjdk.java.net/~srastogi/8149574/webrev10.0/ Regards, Shilpi On 5/13/2016 2:09 PM, Paul Sandoz wrote: assert Boolean.TRUE.equals(ok) : ok;

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

> On 13 May 2016, at 09:13, shilpi.rast...@oracle.com wrote: > > Thank you Vladimir for comments. > > Please review updated webrev > http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/ > Just one minor comment (last one i promise!): 1140 MethodHandle vamh =

Re: MethodHandle for array length

Hi Uwe, I was planning to add a bug for this feature but it seems that Michael was faster than me, https://bugs.openjdk.java.net/browse/JDK-8156915 regards, Rémi - Mail original - > De: "Uwe Schindler" > À: "Michael Haupt" ,

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Thank you Vladimir for comments. Please review updated webrev http://cr.openjdk.java.net/~srastogi/8149574/webrev.09/ Regards, Shilpi On 5/12/2016 6:12 PM, Vladimir Ivanov wrote: rankly speaking, I'd prefer [2] to be co

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Hi Brent, This looks good. It might also be a good idea to add a test that checks this new implementation detail (the unsynchronized get) that new code will become dependent upon, for example: /* * @test * @bug 8029891 * @summary Test that the Properties.get() method does not