JDK 9 RFR of JDK-8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing

tools/launcher/FXLauncherTest.java This test is known to fail intermittently (JDK-8130392 ), it should be marked accordingly with@key intermittentjtreg tag in the test file. bug: https://bugs.openjdk.java.net/browse/JDK-8157211 webrev:

Re: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg

Looks good, Aleksej. -Joe On 5/16/2016 4:57 PM, Aleks Efimov wrote: Hi, Please review the changes to test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java: 1. The test is skipped by JTREG due to incorrect module name in jtreg @modules tag: javax.xml.bind -> java.xml.bind 2. The

Re: RFR [9]: 8072579: XjcOptionalPropertyTest.java creates files in test.src

Hi Aleksej, The change looks good to me. Best, Joe On 5/16/2016 4:39 PM, Aleks Efimov wrote: Hi, Please, help to review XjcOptionalPropertyTest test modification bug [1]. The list of applied changes: 1. Test files are now generated in jtreg work directory (scratch), instead of test source

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

On 18/05/2016 11:46 AM, Brent Christian wrote: Hi! Here's the final(?) webrev: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ with the following changes since the last one: No further comments from me. Thanks, David * The @hidden JavaDoc tag has been removed. It can't be

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

> On May 17, 2016, at 6:46 PM, Brent Christian > wrote: > > Hi! > > Here's the final(?) webrev: > http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ +1 Nit: line 132, 134 in PropertiesSerialization.java test are long lines that should be wrapped to

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

Hi! Here's the final(?) webrev: http://cr.openjdk.java.net/~bchristi/8029891/webrev.6/webrev/ with the following changes since the last one: * The @hidden JavaDoc tag has been removed. It can't be used due to methods disappearing from the API page. Living with the additional JavaDoc is

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 5/17/16 1:09 PM, Peter Levart wrote: I don't think it's possible to have a single form for all new serializable objects in java.util. The java.util package isn't as cohesive as java.time. There's a bunch of random stuff in it. Consider the non-serializable things currently in java.util:

Re: RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline

Hi, the first block in Stream.java bothers me: + * A stream implementation is permitted significant latitude in optimizing + * the computation of the result. For example, a stream implementation is free + * to elide operations (or entire stages) from a stream pipeline -- and + * therefore

Re: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped

Ok to push joe > On May 17, 2016, at 3:37 PM, huizhe wang wrote: > > Thanks Lance! > > On 5/17/2016 11:26 AM, Lance Andersen wrote: >> Hi Joe >> >> It looks OK. The formatting is a bit off where you encased existing code >> with new if statements so I would

RFR 8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130023-stream-elide-ops-side-effects/webrev/ This is a spec tweak to streams to state that implementations are free to elide some

Re: RFR(s): 8133977 add specification for serial form of immutable collections

Hi Stuart, On 05/17/2016 09:03 PM, Stuart Marks wrote: On 5/17/16 3:43 AM, Chris Hegarty wrote: The JSR 310 Serialization framework is a little more involved, as you know. I wonder if it is worth following that pattern more closely here? That way java.util.Ser could be a generic proxy for

Re: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped

Thanks Lance! On 5/17/2016 11:26 AM, Lance Andersen wrote: Hi Joe It looks OK. The formatting is a bit off where you encased existing code with new if statements so I would consider fixing that before you push It seems it has something to do with whitespaces. I re-generated the webrev.

Re: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

Thanks Paul and Claes, pushed. -Aleksey On 05/17/2016 10:16 PM, Claes Redestad wrote: > +1 > > On 2016-05-17 18:46, Aleksey Shipilev wrote: >> Hi, >> >> Now that jdk9/hs merged to jdk9/dev, we can finally make a move to >> connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles:

Re: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

+1 On 2016-05-17 18:46, Aleksey Shipilev wrote: Hi, Now that jdk9/hs merged to jdk9/dev, we can finally make a move to connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: https://bugs.openjdk.java.net/browse/JDK-8157171 Webrev:

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 5/17/16 3:43 AM, Chris Hegarty wrote: The JSR 310 Serialization framework is a little more involved, as you know. I wonder if it is worth following that pattern more closely here? That way java.util.Ser could be a generic proxy for all new Serializable types in the java.util package, and not

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 5/17/16 1:55 AM, Stephen Colebourne wrote: Stuart, I disagree with using an int for the flags, it should be a byte. If you need future expansion you can use 0xff to indicate it with the parser reacting accordingly. That is the strategy for JSR 310 These techniques have different goals. I

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 5/17/16 3:33 AM, Peter Levart wrote: On 05/17/2016 10:55 AM, Stephen Colebourne wrote: CollSer should not be public, especially not just for serialization reasons. I don't see a compelling reason why. Javadocs mention it by name. By making it Serializable, it is effectively public, so it

Re: RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped

Hi Joe It looks OK. The formatting is a bit off where you encased existing code with new if statements so I would consider fixing that before you push Best Lance > On May 17, 2016, at 12:42 PM, huizhe wang wrote: > > Hi, > > This patch fixes a missing feature in

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 5/17/2016 10:28 PM, Vladimir Ivanov wrote: Could someone please explain why it is not required for this test as i saw we are updating other tests ( http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? The test was fixed in Jigsaw repo [1] in a different way. Before the fix, the

Re: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

> On 17 May 2016, at 18:46, Aleksey Shipilev > wrote: > > Hi, > > Now that jdk9/hs merged to jdk9/dev, we can finally make a move to > connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: > https://bugs.openjdk.java.net/browse/JDK-8157171 > >

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

Could someone please explain why it is not required for this test as i saw we are updating other tests ( http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0e2a2be60453 ) ? The test was fixed in Jigsaw repo [1] in a different way. Before the fix, the test class should be put on boot class path

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 07:50 PM, shilpi.rast...@oracle.com wrote: > On 5/17/2016 7:44 PM, Alan Bateman wrote: >> >> On 17/05/2016 14:34, Martin Buchholz wrote: >>> In jdk8 the /othervm is missing. >>> http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html >>> >> Ah, I assumed we were

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 5/17/2016 7:44 PM, Alan Bateman wrote: On 17/05/2016 14:34, Martin Buchholz wrote: In jdk8 the /othervm is missing. http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html Ah, I assumed we were discussing the version in jdk9/dev. BTW: My interest here is to make sure we

RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

Hi, Now that jdk9/hs merged to jdk9/dev, we can finally make a move to connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: https://bugs.openjdk.java.net/browse/JDK-8157171 Webrev: http://cr.openjdk.java.net/~shade/8157171/webrev.01/ The core changes are in the template

RFR (JAXP) 8156845: Uri is getting incorrectly unwrapped

Hi, This patch fixes a missing feature in CatalogUriResolver where an uri entry can be referenced by a publicid (urn:publicid), similar to that of the public entry. The fix then is basically sharing the process for a public entry. JBS: https://bugs.openjdk.java.net/browse/JDK-8156845

Re: JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java

Look fine Hamlin; cheers, -Joe On 5/17/2016 1:04 AM, Hamlin Li wrote: Would you please review the change to problem list 2 frequently failing tests. Thank you -Hamlin On 2016/5/16 15:39, Hamlin Li wrote: java/io/pathNames/GeneralWin32.java has been seen to fail with high frequency on

Re: Can an object be finalized while still weakly reachable?

On 5/17/16 12:55 AM, Martin Buchholz wrote: Thanks, Peter. My current theory is indeed that I made a mistake, and have encountered my first real finalization resurrection bug. ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! there was a long discussion when we touched that

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

Note that the two existing catch blocks 243 } catch (Exception t) { 244 t.printStackTrace(System.err); 245 failed.add(s); 246 } catch (NoClassDefFoundError e) { 247 e.printStackTrace(System.err); 248 failed.add(s); 249

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 05/17/2016 04:26 PM, Sundararajan Athijegannathan wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ Yes, reviewed. Thanks, -Aleksey

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 17/05/2016 14:34, Martin Buchholz wrote: In jdk8 the /othervm is missing. http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html Ah, I assumed we were discussing the version in jdk9/dev. BTW: My interest here is to make sure we didn't break anything with the module system

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

In jdk8 the /othervm is missing. http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html On Tue, May 17, 2016 at 6:20 AM, Alan Bateman wrote: > > > On 17/05/2016 13:21, shilpi.rast...@oracle.com wrote: >> >> Gentle Reminder! >> >>

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 17/05/2016 14:26, Sundararajan Athijegannathan wrote: Please review the updated webrev: http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ This version looks okay to me. Now let's see if I find out where the bad class is coming from. -Alan

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

Please review the updated webrev: http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ Thanks, -Sundar On 5/17/2016 6:42 PM, Alan Bateman wrote: > On 17/05/2016 14:08, Aleksey Shipilev wrote: >> On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: >>> Please review

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 17/05/2016 13:21, shilpi.rast...@oracle.com wrote: Gentle Reminder! https://bugs.openjdk.java.net/browse/JDK-8155791 http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ Is this test failing? I can't quite tell why it needs to be on the boot class path, -Alan.

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 17/05/2016 14:08, Aleksey Shipilev wrote: On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157146 Shouldn't it follow the same pattern other catch blocks? Surely you

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157146 Shouldn't it follow the same pattern other catch blocks? Surely you want to run all test cases, and not abort on

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 17/05/2016 10:58 PM, Aleksey Shipilev wrote: On 05/17/2016 03:45 PM, shilpi.rast...@oracle.com wrote: On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8155791

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 03:45 PM, shilpi.rast...@oracle.com wrote: > On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: >> On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>> http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ > Parse

RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157146 This is test only change to debug printlns. Thanks, -Sundar

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: Gentle Reminder! https://bugs.openjdk.java.net/browse/JDK-8155791 http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ Parse Exception: [-esa]: vm option(s) found, need to specify

Re: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg

On 05/17/2016 02:57 AM, Aleks Efimov wrote: > Webrev: http://cr.openjdk.java.net/~aefimov/8157096/9/00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8157096 Looks good. Thanks, -Aleksey

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: > Gentle Reminder! > > https://bugs.openjdk.java.net/browse/JDK-8155791 > http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm Still not getting this. The

Re: RFR 8154192: Deprivilege java.scripting module

On 17/05/2016 13:04, Sundararajan Athijegannathan wrote: Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 java.scripting module is assigned to platform class loader (instead of boot loader). And java.scripting module is given AllPermission [previously it had AllPermission

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

Gentle Reminder! https://bugs.openjdk.java.net/browse/JDK-8155791 http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ On 5/12/2016 3:06 PM, Michael Haupt wrote: Hi Shilpi, thanks for the clarification. OK by me then - please note this is a lower-case review. Best, Michael Am

Re: RFR 8154192: Deprivilege java.scripting module

+1 > On May 17, 2016, at 9:04 AM, Sundararajan Athijegannathan > wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And

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

On 15/05/2016 19:54, Xueming Shen wrote: Thanks Alan, Here is the webrev with the first proposed change. http://cr.openjdk.java.net/~sherman/8147588/webrev/ -sherman It needs a bit of clean-up but I think we can live with the approach. One thing that could be cleaned up is to move the

RFR 8154192: Deprivilege java.scripting module

Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 java.scripting module is assigned to platform class loader (instead of boot loader). And java.scripting module is given AllPermission [previously it had AllPermission implicitly because of being boot loader code] jdk repo:

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 17 May 2016, at 12:38, Stephen Colebourne wrote: > I've just checked, and yes the 310 Ser class is more involved (and > more efficient) as it implements Externalizable. (Externalizable saves > bytes over Serializable, by taking full control of the output IIRC). Right.

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

I would also like to see the test case methods be named "getFrom" not "getfrom". Stephen On 17 May 2016 at 05:18, nadeesh tv wrote: > Hi Bhanu, > > I think you should add a test case comparing the return value of getFrom() > >( Not an official reviewer) > > Regards, >

Re: RFR(s): 8133977 add specification for serial form of immutable collections

I've just checked, and yes the 310 Ser class is more involved (and more efficient) as it implements Externalizable. (Externalizable saves bytes over Serializable, by taking full control of the output IIRC). While criticisms of the 310 design are welcome, it was carefully crafted to be a generally

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 17 May 2016, at 09:55, Stephen Colebourne wrote: > CollSer should not be public, especially not just for serialization > reasons. Right, and I see no reason to refer to it by name in the javadoc, the link should be sufficient. > Stuart, I disagree with using an int

Re: RFR(s): 8133977 add specification for serial form of immutable collections

On 05/17/2016 10:55 AM, Stephen Colebourne wrote: CollSer should not be public, especially not just for serialization reasons. I don't see a compelling reason why. Javadocs mention it by name. By making it Serializable, it is effectively public, so it can't go away or be renamed. What is

Re: RFR 8156485 MethodHandles.varHandleExactInvoker should perform exact checks

> On 16 May 2016, at 13:52, Vladimir Ivanov > wrote: > > Looks good. > Thanks. > Best regards, > Vladimir Ivanov > > PS: regarding naming, makeVarHandleMethodInvoker is shorter and as > informative. Since there are only 2 flavors of invokers for VarHandles

Re: Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

Hi Jaroslav, I would prefer not to spread such functionality beyond that of ByteBuffer and the VarHandle producing methods on MethodHandles. It’s an advanced feature so think ok if less visible. Note at the moment a VarHandle produced for byte[]/ByteBuffer view is not cached but it is

Re: RFR(s): 8133977 add specification for serial form of immutable collections

CollSer should not be public, especially not just for serialization reasons. Stuart, I disagree with using an int for the flags, it should be a byte. If you need future expansion you can use 0xff to indicate it with the parser reacting accordingly. That is the strategy for JSR 310 Stephen On 17

Re: JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java

Would you please review the change to problem list 2 frequently failing tests. Thank you -Hamlin On 2016/5/16 15:39, Hamlin Li wrote: java/io/pathNames/GeneralWin32.java has been seen to fail with high frequency on windows. Until JDK-8156595 is addressed, the test should be problem listed.

Re: Can an object be finalized while still weakly reachable?

Thanks, Peter. My current theory is indeed that I made a mistake, and have encountered my first real finalization resurrection bug. ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play! My static reference was finalized because it used to be unreachable, not because it is now

Re: RFR(s): 8133977 add specification for serial form of immutable collections

Hi Stuart, On 05/17/2016 12:48 AM, Stuart Marks wrote: Hi all, Please review this changeset that adds specifications of the serialized forms (really, a single serialization proxy class) for the immutable collections implementation. There are no code changes in this changeset, just

Re: Can an object be finalized while still weakly reachable?

Hi Martin, On 05/17/2016 05:19 AM, Martin Buchholz wrote: I have some evidence that an object's finalize method can run while a weak reference pointing to it is not yet cleared, which surprised me. E.g. class F { protected void finalize() { assert wref.get() != this; } } static WeakReference