Re: RFR: 8168073: Speed up URI creation during module bootstrap

On 17/10/2016 22:18, Claes Redestad wrote: On 2016-10-17 21:35, Alan Bateman wrote: JavaNetHttpCookieAccess, JavaNetInetAddressAccess and JavaNetSocketAccess are the other 3 that are used to get at non-public types in java.net so I don't think JavaNetUriAccess would be out of place. TIL!

Re: RFR: 8168073: Speed up URI creation during module bootstrap

On 17/10/2016 22:18, Claes Redestad wrote: > >> On 2016-10-17 21:35, Alan Bateman wrote: >>> >>> JavaNetHttpCookieAccess, JavaNetInetAddressAccess and >>> JavaNetSocketAccess are the other 3 that are used to get at non-public >>> types in java.net so I don't think JavaNetUriAccess would be out of

Re: RFR:JDK-8075205 java/net/URLClassLoader/closetest/CloseTest.java and GetResourceAsStream.java failed with existing dir

> On 17 Oct 2016, at 09:51, Srinivasan Raghavan > wrote: > > Hi all > > Please review the fix for the bug > > Bug :https://bugs.openjdk.java.net/browse/JDK-8075205 > > The tests uses classes directory for the output files. This can result in the > files being left over after the test is co

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

Hi Mandy, On 10/18/2016 01:51 AM, Mandy Chung wrote: >Besides, constant names would not be any prettier than class name string literals. At least now it is obvious to anyone what package a particular class belongs to: > > "a.Package" vs. A_PACKAGE ? > PACKAGE_CLASS_IN_PKG_A PUBLIC_SUPERC

RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8071678 Thanks, -Sundar

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

+1 > On Oct 18, 2016, at 8:36 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8071678 > > Thanks, > > -Sundar >

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

+1 Hannes > Am 18.10.2016 um 13:36 schrieb Sundararajan Athijegannathan > : > > Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8071678 > > Thanks, > > -Sundar >

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Hi Alan, On 10/14/2016 02:16 PM, Alan Bateman wrote: On 13/10/2016 18:30, Peter Levart wrote: Hi Paul, Alan, I incorporated Paul's suggestions into new webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.05/ This iteration also contains a nearly-exhaustive t

Re: RFR: 8163984: Fix license and copyright headers in jdk9 under test/lib

Hi, I'm still looking for volunteers to review Best regards, Stanislav Smirnov > On 05 Oct 2016, at 19:44, Stanislav Smirnov > wrote: > > Hi, > > Please review this fix for JDK-8163984 > . > This one is similar to another one, I have sen

Re: RFR: jsr166 jdk9 integration wave 12

On 10/17/16 6:34 PM, Martin Buchholz wrote: Most of this is for Stuart - very collection-y. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ This includes a rewrite of ArrayDeque to bring it to parity with ArrayList (except for List features). The patch includes pu

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

> On Oct 18, 2016, at 3:55 AM, Peter Levart wrote: > > They do. What do you say about this variant (compressionLevel=9): > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/ +1. Ship it! Thanks for compressing it! Mandy

Re: RFR: jsr166 jdk9 integration wave 12

Hi, The j.u.c. changes look ok to me as do the misc changes. The ArrayDeque changes may also change the performance characteristics, a space/time trade-off e.g. in current version array bounds checks are strength reduced to a zero-based test of the array length. Unsure in practice if this real

Re: RFR: jsr166 jdk9 integration wave 12

On Tue, Oct 18, 2016 at 10:15 AM, Stuart Marks wrote: > > > On 10/17/16 6:34 PM, Martin Buchholz wrote: > >> Most of this is for Stuart - very collection-y. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166- >> jdk9-integration/ >> >> This includes a rewrite of ArrayDeque to bring

Re: RFR: 6378384 (reflect) subclass can’t access superclass’s protected fields and methods by reflection

Hi Mandy, On 10/18/2016 07:36 PM, Mandy Chung wrote: On Oct 18, 2016, at 3:55 AM, Peter Levart wrote: They do. What do you say about this variant (compressionLevel=9): http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/ +1. Ship it! Thanks for com

RFR 8163553 java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8163553-vh-mh-link-errors-not-wrapped/webrev/ This is the issue that motivated a change in the behaviour of indy wrapping Errors in BootstrapMethodError, JDK-8166974. I plan to push this issue with JDK-8166974 to hs, since they

JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

Hello, We have a Java Webstart application that uses CORBA and requires an old version of the Visibroker ORB (5.2.1) that will not launch with Java 9 due to its inclusion of a change originally added to 7u55 and later backed out: Bug ID: JDK-8042789 org.omg.CORBA.ORBSingletonClass loading n

Re: RFR: jsr166 jdk9 integration wave 12

On Tue, Oct 18, 2016 at 10:55 AM, Paul Sandoz wrote: > > Testing-wise there is always gonna be some overlap. It would be nice to > consolidate, although arguably in principle TCK has a slightly different > focus. Now that the tck is in the OpenJDK repo perhaps we should add that > to the jdk_coll

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hello, On 10/12/2016 8:50 AM, Roger Riggs wrote: Hi Chris, On 10/10/2016 9:43 AM, Chris Hegarty wrote: Roger, [snip] Right, I was a little uneasy with this too, to being with, but it has grown on me ( since it appears stable and reliable in all my builds and tests ). Also the surface are

Re: JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

On 18/10/2016 19:57, Tom Hood wrote: Hello, We have a Java Webstart application that uses CORBA and requires an old version of the Visibroker ORB (5.2.1) that will not launch with Java 9 due to its inclusion of a change originally added to 7u55 and later backed out: Bug ID: JDK-8042789

Re: RFR: jsr166 jdk9 integration wave 12

> On 18 Oct 2016, at 12:07, Martin Buchholz wrote: > > > > On Tue, Oct 18, 2016 at 10:55 AM, Paul Sandoz wrote: > > Testing-wise there is always gonna be some overlap. It would be nice to > consolidate, although arguably in principle TCK has a slightly different > focus. Now that the tck i

Re: RFR: jsr166 jdk9 integration wave 12

Latest webrev defers potential new methods: /* TODO: public */ private void trimToSize()

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz wrote: > On Tue, Oct 18, 2016 at 10:15 AM, Stuart Marks > > wrote: > > > > > > > On 10/17/16 6:34 PM, Martin Buchholz wrote: > > > >> Most of this is for Stuart - very collection-y. > >> > >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166

Re: RFR: jsr166 jdk9 integration wave 12

On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich wrote: > >> > * Change in allocation/capacity policy. >> > >> > The removal of the power-of-two restriction, and applying a 1.5x growth >> > factor (same as ArrayList) seems sensible. Does this mean that the >> ability >> > to compute the proper

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz wrote: > > > On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich > wrote: > >> >>> > * Change in allocation/capacity policy. >>> > >>> > The removal of the power-of-two restriction, and applying a 1.5x growth >>> > factor (same as ArrayList) seems sen

Re: RFR: jsr166 jdk9 integration wave 12

On Tue, Oct 18, 2016 at 4:26 PM, Vitaly Davidovich wrote: > "jsr166 style" - makes it easy on javac and the JIT, if not for humans. >> > In some of the cases here, I'd consider it a significant JIT failure if > the "jsr166 style" makes a difference (I'm not sure how this makes a > difference to j

Re: RFR: 8163984: Fix license and copyright headers in jdk9 under test/lib

Hi Stanislav, On 19/10/2016 1:06 AM, Stanislav Smirnov wrote: Hi, I'm still looking for volunteers to review This is trivial. Reviewed. I will push for you, to jdk9/dev. Thanks, David Best regards, Stanislav Smirnov On 05 Oct 2016, at 19:44, Stanislav Smirnov wrote: Hi, Please re

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz wrote: > > > On Tue, Oct 18, 2016 at 4:26 PM, Vitaly Davidovich > wrote: > >> "jsr166 style" - makes it easy on javac and the JIT, if not for humans. >>> >> In some of the cases here, I'd consider it a significant JIT failure if >> the "jsr166 style"

Re: JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

It's unclear if there really is an interop issue. The application will launch with 7u55 if I don't set the ORBSingletonClass property, although that isn't how visibroker 5.2.1 was intended to run, so not setting it worries me. Our application does call ORB.init(args,props) once at startup and us

Re: RFR: jsr166 jdk9 integration wave 12

On Tue, Oct 18, 2016 at 6:33 PM, Vitaly Davidovich wrote: > > Indeed - the whole inlining based on simple bytecode size is a big problem > (I've brought this up in various contexts several times on the compiler > list, but this is a known issue). But, some of the methods using the jsr > style lo

Re: RFR:JDK-8075205 java/net/URLClassLoader/closetest/CloseTest.java and GetResourceAsStream.java failed with existing dir

Thanks for the review. > On 18-Oct-2016, at 4:16 PM, Chris Hegarty wrote: > > >> On 17 Oct 2016, at 09:51, Srinivasan Raghavan >> wrote: >> >> Hi all >> >> Please review the fix for the bug >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8075205 >> >> The tests uses classes directory

RFR 8071588: The spec for javax.script.ScriptEngineFactory.getProgram() should specify NPEs thrown

Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8071588 jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/ nashorn webrev: http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/ Thanks -Sundar

Re: RFR: 8163984: Fix license and copyright headers in jdk9 under test/lib

David, thank you Best regards, Stanislav Smirnov > On 19 Oct 2016, at 04:27, David Holmes wrote: > > Hi Stanislav, > > On 19/10/2016 1:06 AM, Stanislav Smirnov wrote: >> Hi, >> >> I'm still looking for volunteers to review > > This is trivial. Reviewed. I will push for you, to jdk9/dev.