Re: Race Condition in initializeEncoding() function in jni_util.c

Hi Ron, On 11/11/2016 1:01 AM, Ronald Servant wrote: Hi, While building the J9 JVM for the IBM SDK for Java(*), we've run across what we believe is a race condition in initializeEncoding(JNIEnv*) in jni_util.c. I suspect there is an assumption of single-threaded initialization of the syste

RE: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Hi Roger, Thanks for the review. I have updated the test to set default locale (and restore it) in only those methods which were causing problem in non English locales. Please review the updated webrev below: Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/ Thank

Re: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

+1 On 11/11/2016 1:48 AM, Martin Buchholz wrote: Looks good! On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK8U. Since tzdata is cumulative, this bug fix backports both the tzdata versions(tzdata2016h+tzdata2016i

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

On 11/11/2016 8:46 AM, Mandy Chung wrote: On Nov 10, 2016, at 2:28 PM, Peter Levart wrote: On 11/10/2016 05:59 PM, Alan Bateman wrote: On 10/11/2016 17:42, David M. Lloyd wrote: My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just th

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

> On Nov 10, 2016, at 2:28 PM, Peter Levart wrote: > > On 11/10/2016 05:59 PM, Alan Bateman wrote: >> >> >> On 10/11/2016 17:42, David M. Lloyd wrote: >>> My original suggestion for the method was to make it static, and possibly >>> even caller-sensitive, for just this reason. >> Changing it

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

On 11/10/2016 05:59 PM, Alan Bateman wrote: On 10/11/2016 17:42, David M. Lloyd wrote: My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. Changing it to be non-final looks reasonable here, the main reason being that it's a no

Re: 8169001: Remove launcher's built-in ergonomics

Looks good! Thanks, David On 11/11/2016 7:10 AM, Kumar Srinivasan wrote: Hi David, Here is the updated revision * added back in FreeUnknowVMS * add -client KNOWN as you suggested delta webrev http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ full webrev (for reference): http

Re: 8169001: Remove launcher's built-in ergonomics

Hi David, Here is the updated revision * added back in FreeUnknowVMS * add -client KNOWN as you suggested delta webrev http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ full webrev (for reference): http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/ Thanks Kumar On 11/7/

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Jochen, Can you confirm if my analysis of Groovy using ClassValue was correct: https://bugs.openjdk.java.net/browse/JDK-8136353 AFAICT in this case the issue was not with ClassValue itself but the storing of computed values in a global se

Re: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods

+1 Thanks, Brian On Nov 10, 2016, at 11:17 AM, Chris Hegarty wrote: > On 10 Nov 2016, at 19:09, Roger Riggs wrote: >> >> Hi, >> >> Please review this request to enable instrumentation on the FileInputStream >> skip and available methods >> by wrapping native methods with java methods as pr

Re: RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods

On 10 Nov 2016, at 19:09, Roger Riggs wrote: > > Hi, > > Please review this request to enable instrumentation on the FileInputStream > skip and available methods > by wrapping native methods with java methods as proposed and contributed by > Sunny Chan. > > webrev: > http://cr.openjdk.java.n

RFR 9: 8169556 : Wrap FileInputStream's native skip and available methods

Hi, Please review this request to enable instrumentation on the FileInputStream skip and available methods by wrapping native methods with java methods as proposed and contributed by Sunny Chan. webrev: http://cr.openjdk.java.net/~rriggs/webrev-fis-native-wrap-8169556/ Issue: https://bug

Re: Review request: JDK-8168386: Fix jdeps verbose options

Hi Mandy, This looks OK. Best Lance > On Nov 9, 2016, at 10:01 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168386/webrev.00 > > This patch tightens the option validation to jdeps and the new test shows > some example of conflicting options. > > Mandy

[9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. JBS: https://bugs.openjdk.java.net/browse/JDK-8169289 Webrev: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ For reference, here are the openjfx changes needed: http

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

On 10/11/2016 17:42, David M. Lloyd wrote: My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. Changing it to be non-final looks reasonable here, the main reason being that it's a no-arg is method and so unlikely that there

Re: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

Looks good! On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2016i) to JDK8U. > Since tzdata is cumulative, this bug fix backports both the tzdata > versions(tzdata2016h+tzdata2016i) into jdk8u. > > Bug: https://bugs.openjdk.ja

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. On 11/09/2016 04:53 PM, Brent Christian wrote: Hi, It seems that the method name used in 8165793[1], "isParallelCapable", was a little *too* intuitive. An existing use of tha

RFR: 8169495: Add a method to set an Authenticator on a HttpURLConnection.

Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8169495 8169495: Add a method to set an Authenticator on a HttpURLConnection. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169495/webrev.00 The public API changes are in java.net.HttpURLConnection and java.net.Au

Race Condition in initializeEncoding() function in jni_util.c

Hi, While building the J9 JVM for the IBM SDK for Java(*), we've run across what we believe is a race condition in initializeEncoding(JNIEnv*) in jni_util.c.       (*)  The IBM SDK for Java is comprised of the J9 JVM and OpenJDK class library. We've encountered a situation where (*env)->CallObj

Re: JDK 9 RFR of JDK-8169041: com/sun/corba/cachedSocket should be added to exclusiveAccess.dirs

Looks ok Amy. -Chris. > On 10 Nov 2016, at 03:31, Amy Lu wrote: > > Please review the patch to add com/sun/corba/cachedSocket to > exclusiveAccess.dirs so as tests won't run concurrently. > > This is to address one potential issue that corba tests (start and use orbd > service) may run into

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

Hi Andrey, No, it isn't. I submitted a new CR: https://bugs.openjdk.java.net/browse/JDK-8167384. Thank you, Denis. > Hi, > > Looks OK. Is it 100% pass rate? > > —Andrey > > On 9 Nov 2016, at 20:36, Denis Kononenko > wrote: > > > > > > > > Hi, > > > > After discussion with Andrey we dec

RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK8U. Since tzdata is cumulative, this bug fix backports both the tzdata versions(tzdata2016h+tzdata2016i) into jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev: http://cr.openjdk.java.net/~rpatil/8169537/web

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

On 09.11.2016 19:18, Doug Lea wrote: [...] And: Similar cases can indeed occur with ThreadLocal, but users seem to mostly avoid them, sometimes after painful experience. ThreadLocal is already a bad choice once you subclass it. bye Jochen

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

On 09.11.2016 17:47, Paul Sandoz wrote: Hi Peter, Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more