Re: RFR 8157530/9, Remove intermittent key from javax/net/ssl/DTLS/WeakCipherSuite.java

Looks fine to me. Thanks, Xuelei On 6/20/2016 1:52 PM, Felix Yang wrote: > javax/net/ssl/DTLS/WeakCipherSuite.java failed intermittently with > (JDK-8129389 ). It had > been resolved and no new failure was observed in pass round of same > binaries

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

On 17/06/2016 10:20 PM, Claes Redestad wrote: On 2016-06-17 03:35, David Holmes wrote: Hi Claes, On 17/06/2016 8:20 AM, Claes Redestad wrote: Isn't this variable unused now: 63 boolean vmAllowSuspension; Interestingly enough there are hooks in hotspot to compute offsets of various f

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

On 2016-06-20 14:42, David Holmes wrote: On 17/06/2016 10:20 PM, Claes Redestad wrote: On 2016-06-17 03:35, David Holmes wrote: On 17/06/2016 8:20 AM, Claes Redestad wrote: HS: http://cr.openjdk.java.net/~redestad/8159590/hotspot.02/ JDK: http://cr.openjdk.java.net/~redestad/8159590/jdk.

Re: [9] RFR: 8159548: Formatter returns unexpected strings if locale is null.

Kindly reminder... Naoto On 6/16/16 2:48 PM, Naoto Sato wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8159548 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8159548/webrev.00/ The previous fix to 8146156 overly localize

RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi, Please find below a patch for: 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code. Issue: https://bugs.openjdk.java.net/browse/JDK-8150173 Patch: http://cr.openjdk.java.net/~dfuchs/webrev_8159245

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

Hi Remi, > do you have checked that the your patch doesn't load a bunch of supplementary > classes at start-up ? > because JarFile is used at start-up, it triggers the load of Runtime.Version > and Runtime.Version has a dependency on a dozen of classes in java.util.regex. Is it still true, in J

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

On 6/13/16 5:14 PM, Naoto Sato wrote: On 13/06/2016 16:20, Brent Christian wrote: Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country So does this mean the new code will not honor the "Region" in the OSX's system prefer

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Good! Wasn't aware there is "British English" in the language selection. Looks like all is working as expected. Naoto On 6/20/16 2:34 PM, Brent Christian wrote: On 6/13/16 5:14 PM, Naoto Sato wrote: On 13/06/2016 16:20, Brent Christian wrote: Following the call to setupMacOSXLocale() in Par

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Alex - thanks for your response. More below... On 6/13/16 4:51 PM, Alex Strange wrote: 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (l

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Hi, I have an updated webrev at: http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ The comments have been updated as Gerard suggested. The code to process the languageString now accounts for 3-character language codes, and 4-char script designations (line 86). More extensive testing of

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi Daniel, I just has one simple question. In new version, in Logger::importConfig, userParentHandlers, filter, levelObject are copied from other(ConfigurationData) unconditionally, handlers in other are only *copied *when it's empty in system. In previous version, handlers in other are *added

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

On 21/06/16 04:29, Hamlin Li wrote: Hi Daniel, I just has one simple question. In new version, in Logger::importConfig, userParentHandlers, filter, levelObject are copied from other(ConfigurationData) unconditionally, handlers in other are only *copied *when it's empty in system. In previous ver