RFR: jsr166 jdk9 integration wave 12

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 public methods ensureCapacity, trimToSize,

Re: RFR(xs): 8168096: markup error in "since" element spec of @Deprecated

+1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Oct 17, 2016, at 7:20 PM, Stuart Marks wrote: > > Hi all, please review this tiny

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

On 10/17/16 5:16 PM, Paul Sandoz wrote: On 17 Oct 2016, at 16:36, John Rose wrote: On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote: On 17 Oct 2016, at 15:01, Stuart Marks wrote: Usually I wrinkle my nose at a throw

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

On 18/10/2016 10:09 AM, Paul Sandoz wrote: On 17 Oct 2016, at 15:33, David Holmes > wrote: Hi Paul, Looking at hotspot changes only ... On 15/10/2016 8:08 AM, Paul Sandoz wrote: Hi, Please review:

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 16:36, John Rose wrote: > > On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote: >> >> >>> On 17 Oct 2016, at 15:01, Stuart Marks wrote: >>> >>> Hi Paul, >>> >>> I took a look at the jdk changes. They

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 15:33, David Holmes wrote: > > Hi Paul, > > Looking at hotspot changes only ... > > On 15/10/2016 8:08 AM, Paul Sandoz wrote: >> Hi, >> >> Please review: >> >> >>

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

> On Oct 17, 2016, at 4:30 PM, Peter Levart wrote: > > ...you would review the members that are allowed and then you should ask > yourself: "Which are the ones that are denied? All the rest. What are they?", > or: "Could there be any other that should be allowed? Which

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

On Oct 17, 2016, at 3:38 PM, Paul Sandoz wrote: > > >> On 17 Oct 2016, at 15:01, Stuart Marks wrote: >> >> Hi Paul, >> >> I took a look at the jdk changes. They look good to me. >> >> One section of code gave me pause, which is the throw of

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

Hi Mandy, On 10/17/2016 10:52 PM, Mandy Chung wrote: On Oct 16, 2016, at 11:18 AM, Peter Levart wrote: I think specifying both is more verbose on one hand, but OTOH it allows one to visually inspect all the cases and think of each and every one in isolation to see

Re: RFR(xs): 8168096: markup error in "since" element spec of @Deprecated

+1 -Joe On 10/17/2016 4:20 PM, Stuart Marks wrote: Hi all, please review this tiny fix to the javadoc markup in the Deprecated annotation type. Thanks, s'marks --- a/src/java.base/share/classes/java/lang/Deprecated.javaThu Oct 13 23:02:35 2016 + +++

RFR(xs): 8168096: markup error in "since" element spec of @Deprecated

Hi all, please review this tiny fix to the javadoc markup in the Deprecated annotation type. Thanks, s'marks --- a/src/java.base/share/classes/java/lang/Deprecated.java Thu Oct 13 23:02:35 2016 + +++ b/src/java.base/share/classes/java/lang/Deprecated.java Mon Oct 17 16:18:26 2016

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

> On 17 Oct 2016, at 15:01, Stuart Marks wrote: > > Hi Paul, > > I took a look at the jdk changes. They look good to me. > > One section of code gave me pause, which is the throw of ClassCastException > at 339 of CallSite.java, and the throw of the exception returned

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

Hi Paul, Looking at hotspot changes only ... On 15/10/2016 8:08 AM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/

Re: RFR 8166974: invokedynamic implementation should not wrap Errors

Hi Paul, I took a look at the jdk changes. They look good to me. One section of code gave me pause, which is the throw of ClassCastException at 339 of CallSite.java, and the throw of the exception returned from wrongTargetType() at 344 of CallSite.java. This appears odd given the "rethrow

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

> On Oct 17, 2016, at 2:18 PM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8168073/webrev.02/ +1 Mandy

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

> On 17 Oct 2016, at 14:18, Claes Redestad wrote: > > > > On 2016-10-17 21:35, Alan Bateman wrote: >> >> >> On 17/10/2016 19:45, Claes Redestad wrote: >>> >>> Most other SharedSecrets classes seems to be per-package, so not sure >>> if this case is special enough

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

On 2016-10-17 21:35, Alan Bateman wrote: On 17/10/2016 19:45, Claes Redestad wrote: Most other SharedSecrets classes seems to be per-package, so not sure if this case is special enough to start making them per-class, other than the slightly more natural naming. JavaNetHttpCookieAccess,

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

> On Oct 16, 2016, at 11:18 AM, Peter Levart wrote: > > > I think specifying both is more verbose on one hand, but OTOH it allows one > to visually inspect all the cases and think of each and every one in > isolation to see if it is valid in a particular

RFR: 8168093: Need a way for the launcher to query the JRE location using Windows registry.

Hello, I am sponsoring this patch for the client team, the issue here is that the Windows installer copies the java launcher binaries to a system folder, and those binaries need to locate the Java Runtime using Windows registry. These changes are to allow calling an internal (Registry locator)

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

> On 17 Oct 2016, at 10:53, Claes Redestad wrote: > > Hi Paul, > > On 2016-10-17 19:39, Paul Sandoz wrote: >> Hi Claes, >> >> This looks good. > > Thanks! > >> >> Did you consider adding asserts to the package private constructor? > > No, might be reasonable. Do

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

> On Oct 17, 2016, at 11:07 AM, Alan Bateman wrote: > > > > On 17/10/2016 12:17, Claes Redestad wrote: >> Hi, >> >> one partial cause for startup regressions due to jigsaw is related to >> creating >> URIs for the location of each module. >> >> By providing a

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

On 17/10/2016 19:45, Claes Redestad wrote: Most other SharedSecrets classes seems to be per-package, so not sure if this case is special enough to start making them per-class, other than the slightly more natural naming. JavaNetHttpCookieAccess, JavaNetInetAddressAccess and

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

On 2016-10-17 20:07, Alan Bateman wrote: On 17/10/2016 12:17, Claes Redestad wrote: Hi, one partial cause for startup regressions due to jigsaw is related to creating URIs for the location of each module. By providing a package-private constructor we can avoid the time to scan and

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

On 17/10/2016 12:17, Claes Redestad wrote: Hi, one partial cause for startup regressions due to jigsaw is related to creating URIs for the location of each module. By providing a package-private constructor we can avoid the time to scan and validate the URI, which takes a little time

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

Hi Paul, On 2016-10-17 19:39, Paul Sandoz wrote: Hi Claes, This looks good. Thanks! Did you consider adding asserts to the package private constructor? No, might be reasonable. Do you insist? :-) /Claes Paul. On 17 Oct 2016, at 04:17, Claes Redestad

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

Hi Paul, On 2016-10-17 19:39, Paul Sandoz wrote: Hi Claes, This looks good. Thanks! Did you consider adding asserts to the package private constructor? No, might be reasonable. Do you insist? :-) /Claes Paul. On 17 Oct 2016, at 04:17, Claes Redestad

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

Hi Claes, This looks good. Did you consider adding asserts to the package private constructor? Paul. > On 17 Oct 2016, at 04:17, Claes Redestad wrote: > > Hi, > > one partial cause for startup regressions due to jigsaw is related to creating > URIs for the

RFR: 8168073: Speed up URI creation during module bootstrap

Hi, one partial cause for startup regressions due to jigsaw is related to creating URIs for the location of each module. By providing a package-private constructor we can avoid the time to scan and validate the URI, which takes a little time (executes ~80K bytecodes) but also pushes

Re: Process to add some default methods to javax.naming.Context?

Please file an RFE for this issue so that the core-libs team can evaluate. While this seems like a good use for default methods, it may be difficult to justify including a convenience method at this late stage in the JDK 9 schedule. Thanks. > On 14 Oct 2016, at 22:21, Laird Nelson

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

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 complete which can result in instability. The tests copies the files to be