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: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

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

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

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. >>> >>

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

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

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

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. > >> >

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 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

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: [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

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

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

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

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.

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

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

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!

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

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

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

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 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 >

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: 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

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

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

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!