Re: Demo for Parallel Core Collection API

On Feb 4, 2014, at 2:58 AM, Tristan Yan wrote: > Hi Paul > I know this may be a little bit late. Yes, likely too late... (see below). > But I am still asking you review this. > > http://cr.openjdk.java.net/~tyan/JDK-8033358/webrev.01/ > > This is a whole demo code include the stream demo code

8033372: Check jdk/src/share/native/java/lang for JNI pending exception issues

There are a number of places in the native methods where there are sequences of JNI calls and where we don't check for errors or pending exceptions. This patch fixes up a number of these issues in the java.lang native code, and one remaining one in the java.io native code that may have been m

Re: ObjectIn/OutputStream improvements

On Feb 3, 2014, at 11:01 PM, Stuart Marks wrote: > Nobody took the bait on this yet? :-) > > Certainly there's a lot of semi-myth on this topic, on both sides. Here's my > source of mythology (or urban legend, as one might have it): > > http://www.ibm.com/developerworks/java/library/j-jtp0927

Re: 8033372: Check jdk/src/share/native/java/lang for JNI pending exception issues

Nice work. Looks good to me. -Chris. On 02/04/2014 10:35 AM, Alan Bateman wrote: There are a number of places in the native methods where there are sequences of JNI calls and where we don't check for errors or pending exceptions. This patch fixes up a number of these issues in the java.lang na

Re: JDK 9 RFR of JDK-8033527: Fix raw type lint warning in sun.nio.ch

+1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 4, 2014, at 1:09 AM, Joe Darcy wrote: > Hello, > > Please review this small fix to address > >JDK-8033

RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

Looking to correct some JNI handling code in java/util/zip for jdk9-dev. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/ regards, Sean.

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

Looks good to me. Thanks Sean. -Chris. On 02/04/2014 01:31 PM, Seán Coffey wrote: Looking to correct some JNI handling code in java/util/zip for jdk9-dev. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/ regards

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

On 04/02/2014 13:31, Seán Coffey wrote: Looking to correct some JNI handling code in java/util/zip for jdk9-dev. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/ Looks good. A minor comment is that the ZipFile.c c

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

thanks for reviews. webrev updated : http://cr.openjdk.java.net/~coffeys/webrev.8029020.v2/webrev/ I'll push pending positive build & test results. regards, Sean. On 04/02/14 13:51, Alan Bateman wrote: On 04/02/2014 13:31, Seán Coffey wrote: Looking to correct some JNI handling code in java/ut

RFR: Checking for JNI Exceptions in jni_util.c

Please review these cleanups to check for JNI pending exceptions in jni_util.c. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ Thanks, Roger

Re: RFR: Checking for JNI Exceptions in jni_util.c

Looks good to me Roger. -Chris. On 02/04/2014 02:33 PM, roger riggs wrote: Please review these cleanups to check for JNI pending exceptions in jni_util.c. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ Thanks, Roger

Re: RFR: Checking for JNI Exceptions in jni_util.c

On 04/02/2014 14:33, roger riggs wrote: Please review these cleanups to check for JNI pending exceptions in jni_util.c. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ This mostly looks okay, I just wonder about the jclass declarations at L686 and 690 as I assume t

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

On 04/02/2014 14:10, Seán Coffey wrote: thanks for reviews. webrev updated : http://cr.openjdk.java.net/~coffeys/webrev.8029020.v2/webrev/ Looks good to me. -Alan.

Re: RFR : 8029020 : Check src/share/native/java/util/zip code for JNI pending exceptions

On 2/4/14 5:31 AM, Seán Coffey wrote: Looking to correct some JNI handling code in java/util/zip for jdk9-dev. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/ regards, Sean. looks fine.

ArrayList.removeAll()/retainAll()

Hi, I notice this (or a related issue) has been mentioned beforeon this list, but I'm not convinced the correct resolution was reached. We are seeing this problem thrown by antlr, but rather than a bug in antlr, as surmise

Re: ArrayList.removeAll()/retainAll()

I don't follow. It looks like ArrayList is throwing an exception on removeAll(null) -- perfectly valid, in the spec -- not throwing an exception when the collection contains null. Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Tue, Feb 4, 2014 at 9:00 AM

Re: ArrayList.removeAll()/retainAll()

Ah. I'm a hasty idiot. If you could all pretend I never sent that email, that would be great. On 4 February 2014 17:22, Louis Wasserman wrote: > I don't follow. It looks like ArrayList is throwing an exception on > removeAll(null) -- perfectly valid, in the spec -- not throwing an > exception

答复: Demo for Parallel Core Collection API

Thank you Paul. I was told maybe we will target this on 8u20 if we can't catch 8. Let's do the open review first. http://cr.openjdk.java.net/~tyan/JDK-8033358/webrev.02/ Fibonacci: Update as you suggested. Test shows parallel version is faster than sequential version when the input is greater

Re: ArrayList.removeAll()/retainAll()

The condition that is causing the problem is not a collection containing null, which is allowed, but that the provided collection "c" is itself null. The problem was is a consequence of the following implementation: Iterator iterator = iterator(); while(iterator.hasNext()) { if(c.contains(ite

Re: ArrayList.removeAll()/retainAll()

Hi Mike, Thanks very much for the careful explanation, it's appreciated. It does look trivial to fix, so I'll see about raising a ticket over there. On 4 February 2014 17:35, Mike Duigou wrote: > The condition that is causing the problem is not a collection containing > null, which is allowed,

Re: RFR: Checking for JNI Exceptions in jni_util.c

Hi Alan, Thanks for the review and suggestions; the webrev has been updated with the recommendations. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ Thanks, Roger On 2/4/2014 10:12 AM, Alan Bateman wrote: On 04/02/2014 14:33, roger riggs wrote: Please review thes

RFR - 8033542: test/java/util/logging/SimpleLogManager might let Loggers be gc'ed too early.

Hi, Please find below a fix [1] for: 8033542: test/java/util/logging/SimpleLogManager might let Loggers be gc'ed too early. [2] [1] http://cr.openjdk.java.net/~dfuchs/webrev_8033542/webrev.00 [2] https://bugs.openjdk.java.net/browse/JDK-8033542 The issue is that some of the loggers cr

Re: RFR: Checking for JNI Exceptions in jni_util.c

On 04/02/2014 18:11, roger riggs wrote: Hi Alan, Thanks for the review and suggestions; the webrev has been updated with the recommendations. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exception-8030993/ The updated webrev looks okay. I note in the JNU_ClassXXX functions that th

Re: RFR: Checking for JNI Exceptions in jni_util.c

Hi, Updated the webrev with the recommendations. On 2/4/2014 3:36 PM, Alan Bateman wrote: On 04/02/2014 18:11, roger riggs wrote: Hi Alan, Thanks for the review and suggestions; the webrev has been updated with the recommendations. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check_exce

Re: RFR - 8033542: test/java/util/logging/SimpleLogManager might let Loggers be gc'ed too early.

Thumbs up. Mandy On 2/4/2014 10:18 AM, Daniel Fuchs wrote: Hi, Please find below a fix [1] for: 8033542: test/java/util/logging/SimpleLogManager might let Loggers be gc'ed too early. [2] [1] http://cr.openjdk.java.net/~dfuchs/webrev_8033542/webrev.00 [2] https://bugs.openjdk.java.net