Review Request: JDK-8160698 java --dry-run should not cause main class be initialized

Kumar, I move the call to CreateApplicationArgs before PostJVMInit and dryRun stops before PostJVMInit which shows the splash screen. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160698/webrev.00/index.html This also cleans up the LauncherHelper to use Class::forName instead of

os.name will be "macOS"? (was Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac)

I have an off-topic question: Will os.name be macOS for 10.12? I have several places checking "if (!osname.contains("OS X"))", is there a helper method I can check for this in the future no matter if it's running on pre- or post-10.12? Thanks Max > On Jul 1, 2016, at 2:23 AM, Brent Christian

RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind"

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240 it has been observed that, during continuous integration regression tests on some platforms, there is an

Re: RFR: jsr166 jdk9 integration wave 7

On 06/30/2016 10:08 AM, Paul Sandoz wrote: Hi Peter, Thanks, that’s interesting. I am uncertain if our 166 fellows will be reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. Background: we are reluctant to rely on anything that makes sources impossible to use in

JEP 290: Filter Incoming Serialization Data

New JEP Candidate: http://openjdk.java.net/jeps/290 - Mark

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

On 6/30/16 9:53 AM, Brent Christian wrote: When the minimum Mac build platform is SDK 10.10, we'll be able to call operatingSystemVersion directly without using msgSend. We can also consider removing this then. FYI: https://bugs.openjdk.java.net/browse/JDK-8160676 -Brent

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

> On Jun 30, 2016, at 9:33 AM, Daniel Fuchs wrote: > > Indeed, good catch! I should have seen that :-( > > Here is a patch that should take care of the issue: > > http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.05 > > Thanks for your offline suggestions on

Re: JDK 9 RFR of JDK-6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException could not be serialized

Joe, Caveats and all, that seems like a good solution. +1 Roger On 6/30/2016 1:18 PM, joe darcy wrote: Hello, Please review the changes to address JDK-6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException could not be serialized

JDK 9 RFR of JDK-6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException could not be serialized

Hello, Please review the changes to address JDK-6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException could not be serialized http://cr.openjdk.java.net/~darcy/6226715.0/ Patch below. The analysis of why is patch is valid requires a bit of explanation. Like all other

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

> On Jun 30, 2016, at 7:33 AM, Gerard Ziemski wrote: > > >> On Jun 29, 2016, at 6:47 PM, Mandy Chung wrote: >> >> I think we should move away from testing on unsupported platforms. Is this >> just temporary? when will this be removed? >

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

On 6/29/16 4:47 PM, Mandy Chung wrote: On Jun 29, 2016, at 12:36 PM, Brent Christian wrote: The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. I think we should move away from testing

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Thanks, Brian On 6/29/16 4:35 PM, Brian Burkhalter wrote: Approved. Brian On Jun 29, 2016, at 4:33 PM, Brent Christian > wrote: Thank you, Dave and Gerard. I believe I still need to hear from a JDK9 Reviewer.

Re: RFR 8054213: Class name repeated in output of Type.toString()

Hello Joe, thank you for your advice! GenericStringTest looks really good with annotations. I refactored my test, please see updated webrev: http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ As for "." vs "$" let me

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Will do - thanks, Roger. -Brent On 6/30/16 6:46 AM, Roger Riggs wrote: +1 Can you wrap a couple of very long lines to make the diff easier to read. - 187 - 202 Thanks, Roger On 6/29/2016 7:47 PM, Mandy Chung wrote: On Jun 29, 2016, at 12:36 PM, Brent Christian

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

Hi Mandy, On 21/06/16 17:01, Mandy Chung wrote: On Jun 21, 2016, at 8:39 AM, Daniel Fuchs wrote: I don't understand this scenario. ConfigurationData should remain as simple as possible. Logger.getLogger() / LogManager.demandSystemLogger() will never return a logger

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

Thanks Seán! I added an example of stacktrace to the description. With kind regards, Ivan On 30.06.2016 17:31, Seán Coffey wrote: Looks fine to me Ivan. If you have a stacktrace of an example ConcurrentModificationException issue, please paste it into the bug report so that it's documented

Re: Semantics of VarHandle CAS methods

On Thu, Jun 30, 2016 at 4:19 AM, Doug Lea wrote: > On 06/30/2016 06:38 AM, Martin Buchholz wrote: > >> It's not only about naming. >> >> So yes, I'd like the name weakCompareAndSet to be the sequentially >> consistent version, BUT I'd also expect the next more relaxed version

Re: RFR: jsr166 jdk9 integration wave 7

On 30/06/16 01:04, Doug Lea wrote: On Wed, Jun 29, 2016 at 8:38 AM, Daniel Fuchs > wrote: I mean something like: "The maximum number of spare threads used by the common pool is 256: to arrange the same value as is used by default for

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

> On Jun 29, 2016, at 6:47 PM, Mandy Chung wrote: > >> >> On Jun 29, 2016, at 12:36 PM, Brent Christian >> wrote: >> >> Hi, >> >> Please review the following change for JDK 9: >> >> Bug: >>

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

Looks fine to me Ivan. If you have a stacktrace of an example ConcurrentModificationException issue, please paste it into the bug report so that it's documented for others to find. Regards, Sean. On 24/06/2016 15:56, Ivan Gerasimov wrote: Hi Aleksey! I've double-checked the Pool class and

Re: RFR: jsr166 jdk9 integration wave 7

Hi Peter, Thanks, that’s interesting. I am uncertain if our 166 fellows will be reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. But i note the A*FUs already have a dependency on jdk.internal.reflect.Reflection.getCallerClass(). I like the laziness aspect, but i

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

+1 Can you wrap a couple of very long lines to make the diff easier to read. - 187 - 202 Thanks, Roger On 6/29/2016 7:47 PM, Mandy Chung wrote: On Jun 29, 2016, at 12:36 PM, Brent Christian wrote: Hi, Please review the following change for JDK 9: Bug:

Re: RFR: jsr166 jdk9 integration wave 7

Hi, I noticed that in ThreadLocalRandom and Striped64, Unsafe remains for the sole purpose of accessing 3 fields in java.lang.Thread class. Now that there are VarHandle(s), they could be combined with SharedSecrets to get rid of Unsafe access in those two classes. For example, in Striped64:

Re: RFR: jsr166 jdk9 integration wave 7

Webrev regenerated with updates. Lots of rework for the atomic VarHandle specs. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ In the unlikely case you want the old webrev, it's at

Re: Semantics of VarHandle CAS methods

On 06/30/2016 06:38 AM, Martin Buchholz wrote: It's not only about naming. So yes, I'd like the name weakCompareAndSet to be the sequentially consistent version, BUT I'd also expect the next more relaxed version to be memory_order_acq_rel which we don't provide. There are a few flavors of C++

Re: Semantics of VarHandle CAS methods

It's not only about naming. So yes, I'd like the name weakCompareAndSet to be the sequentially consistent version, BUT I'd also expect the next more relaxed version to be memory_order_acq_rel which we don't provide. I was surprised that weakCompareAndSetAcquire actually does relaxed writes

Re: Semantics of VarHandle CAS methods

> On 30 Jun 2016, at 09:37, Andrew Haley wrote: > > On 30/06/16 02:20, Martin Buchholz wrote: >> VarHandle.compareAndSet is strong in two ways - non-spurious and >> sequentially consistent. >> >> VarHandle.weakCompareAndSet is weak in both these ways. >> (That seems like a

Re: Semantics of VarHandle CAS methods

On 30/06/16 02:20, Martin Buchholz wrote: > VarHandle.compareAndSet is strong in two ways - non-spurious and > sequentially consistent. > > VarHandle.weakCompareAndSet is weak in both these ways. > (That seems like a mistake to me. > The fact that j.u.c. Atomic classes are a precedent for this