RE: RFR: 8189102: All tools should support -?, -h and --help

OK, thanks! Best regards, Goetz. > -Original Message- > From: Weijun Wang [mailto:weijun.w...@oracle.com] > Sent: Wednesday, November 22, 2017 8:08 AM > To: Lindenmaier, Goetz > Cc: core-libs-dev@openjdk.java.net; compiler-...@openjdk.java.net; >

Re: RFR: 8187954 Update JAX-WS RI integration to latest version

Hi, any response? > On Nov 15, 2017, at 08:05, Jack Li wrote: > > Hi Lance > > Is there any other issue about it? can you approve it to merge? > >> On Nov 6, 2017, at 07:59, ZhengJun Li > > wrote: >> >> >>

Re: RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader spec

On 21/11/2017 20:41, Brent Christian wrote: Hi, Please review my change to this small bit of ClassLoader spec that can be tidied up, as noticed by Martin. Issue: https://bugs.openjdk.java.net/browse/JDK-8191173 Webrev: http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/ This looks

Re: RFR: 8189102: All tools should support -?, -h and --help

Hi Goetz I would just remove it. Thanks Max > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz > wrote: > > Hi Max, > > while removing the comments from the k-tools, I saw this: > > --- >

RE: RFR: 8189102: All tools should support -?, -h and --help

Hi Max, while removing the comments from the k-tools, I saw this: --- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java Tue Oct 10 14:39:45 2017 +0200 +++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Thanks Peter for sponsoring this patch. Is there anything else that needs to be done from my end for this patch to be integrated? Please let me know. -Venkat On 14/11/17 8:46 PM, Peter Levart wrote: Hi Venkat, I created the following issue: https://bugs.openjdk.java.net/browse/JDK-8191216

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

On 21 November 2017 at 01:45, Naoto Sato wrote: >> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not. > > Document it in the javadoc. Javadoc looks good, but the webrev didn't contain matching code last time I looked. >> 3)

Re: RFR: JDK-8189611: JarFile versioned stream and real name support

On 21/11/2017 02:58, Xueming Shen wrote: : http://cr.openjdk.java.net/~sherman/8189611/webrev jdeps' VersionHelper.java still accesses the "getRealName()" via the SharedSecrets. Since jdeps is being compiled/built with the bootjdk, I'm leaving it untouched for now. I think we need to

Re: RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks

On Nov 21, 2017, at 9:16 AM, Paul Sandoz wrote: >> Both good points. Updated accordingly: >> http://cr.openjdk.java.net/~bpb/8191516/webrev.01/. >> > > Looks good. How about updating the read method as well to use the bounds > check method? (the len == 0 check makes

Re: RFR: JDK-8189611: JarFile versioned stream and real name support

> On 20 Nov 2017, at 18:58, Xueming Shen wrote: > > Thanks Paul! > > Webrev has been updated as suggested. > > http://cr.openjdk.java.net/~sherman/8189611/webrev > > jdeps' VersionHelper.java still accesses the "getRealName()" via the > SharedSecrets. > Since jdeps

Re: RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks

On Nov 20, 2017, at 6:32 PM, Paul Sandoz wrote: > See also Objects.checkFromIndexSize if you wanna use that instead. > > Also the if len == 0 check is probably redundant, i doubt it makes any > difference given the condition needs to be checked before entering the

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Thanks, Stephen. On 11/21/17 1:35 AM, Stephen Colebourne wrote: On 21 November 2017 at 01:45, Naoto Sato wrote: 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not. Document it in the javadoc. Javadoc looks good, but the webrev didn't contain matching

Re: RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks

> On 21 Nov 2017, at 08:47, Brian Burkhalter > wrote: > > > On Nov 20, 2017, at 6:32 PM, Paul Sandoz > wrote: > >> See also Objects.checkFromIndexSize if you wanna use that instead. >> >> Also the if len

Re: RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks

On Nov 21, 2017, at 9:21 AM, Brian Burkhalter wrote: >> Looks good. How about updating the read method as well to use the bounds >> check method? (the len == 0 check makes sense there)? > > Probably might as well expand it a little to see where else similar

Re: RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks

> On 21 Nov 2017, at 12:30, Brian Burkhalter > wrote: > > On Nov 21, 2017, at 9:21 AM, Brian Burkhalter > wrote: > >>> Looks good. How about updating the read method as well to use the bounds

Re: RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader spec

Looks good! On Tue, Nov 21, 2017 at 12:41 PM, Brent Christian < brent.christ...@oracle.com> wrote: > Hi, > > Please review my change to this small bit of ClassLoader spec that can be > tidied up, as noticed by Martin. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8191173 > Webrev: >

Re: RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader spec

Seems fine. Thanks, David On 22/11/2017 6:41 AM, Brent Christian wrote: Hi, Please review my change to this small bit of ClassLoader spec that can be tidied up, as noticed by Martin. Issue: https://bugs.openjdk.java.net/browse/JDK-8191173 Webrev:

JDK-8191706: Proposal to add Reader::transferTo(Writer)

Hi there out a the review [1] for  JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API. To start

RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader spec

Hi, Please review my change to this small bit of ClassLoader spec that can be tidied up, as noticed by Martin. Issue: https://bugs.openjdk.java.net/browse/JDK-8191173 Webrev: http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/ In java.lang.ClassLoader these methods: getParent()

Re: JDK-8191706: Proposal to add Reader::transferTo(Writer)

Hi Patrick, This looks fine from my point of view. It exactly mirrors InputStream.transferTo(OutputStream) with which I expect everyone will concur. Thanks, Brian On Nov 21, 2017, at 11:56 AM, Patrick Reinhart wrote: > Hi there out a the review [1] for JDK-8066870, that

Re: RFR: JDK-8191706: Add Reader::transferTo(Writer)

Looks good. Of course a corresponding CSR will need to be filed and eventually approved. Thanks, Brian On Nov 21, 2017, at 2:33 PM, Patrick Reinhart wrote: > Here's the implementation and test.. > > http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 > >

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Do we have consensus about changes? I can sponsor and push it. These changes passed Hotspot pre-integration testing and additional requested tests. Thanks, Vladimir On 11/15/17 5:44 AM, Jaroslav Tulach wrote: On úterý 14. listopadu 2017 21:34:45 CET mandy chung wrote: I am wondering this

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On Nov 18, 2017, at 7:34 PM, John Rose wrote: > > On Oct 30, 2017, at 6:50 PM, Stuart Marks wrote: >> >> (also includes 8184690: add Collectors for collecting into unmodifiable >> List, Set, and Map) > > Now I'm going to be picky about the

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On Nov 18, 2017, at 8:10 AM, Brian Goetz wrote: > > I'm with Remi on this. > > Sent from my MacBook Wheel > >> On Nov 18, 2017, at 5:41 AM, Remi Forax > > wrote: >> >> Hi John, >> i strongly believe that static fluent

Re: JDK-8191706: Proposal to add Reader::transferTo(Writer)

Looks good. On 11/21/2017 2:56 PM, Patrick Reinhart wrote: Hi there out a the review [1] for  JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to

RFR 8191736: replace javah w/ javac in jdk tests

Hi. Please take look on this quick fix of removing remains of javah usages from test/jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8191736 Webrev: http://cr.openjdk.java.net/~shurailine/8191736/webrev.00/ Thank you. Shura

RFR: JDK-8191706: Add Reader::transferTo(Writer)

Here's the implementation and test.. http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 -Patrick Am 21.11.2017 um 23:07 schrieb Brian Goetz: > Looks good. > > On 11/21/2017 2:56 PM, Patrick Reinhart wrote: >> Hi there out a the review [1] for  JDK-8066870, that will need some more

Re: RFR: JDK-8191706: Add Reader::transferTo(Writer)

Created https://bugs.openjdk.java.net/browse/JDK-8191737 Any additions welcome -Patrick Am 21.11.2017 um 23:41 schrieb Brian Burkhalter: > Looks good. > > Of course a corresponding CSR will need to be filed and eventually > approved. > > Thanks, > > Brian > > On Nov 21, 2017, at 2:33 PM,

Re: [10] RFR 8191404: Upgrading JDK with latest available LSR data from IANA.

Hi Nishit, One nit in the test. At line 71, probably the original intention of "str" is to list the accept languages in alphabetic order. Would you change it? I have not looked into actual tags in the test. Did you modify them manually? If so, it would be desirable to make it automated.

Re: RFR 8191736: replace javah w/ javac in jdk tests

Shura, Looks OK to me, although I'm not normally a Reviewer for AWT tests. -- Jon On 11/21/17 3:58 PM, Alexandre (Shura) Iline wrote: Hi. Please take look on this quick fix of removing remains of javah usages from test/jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8191736 Webrev:

Re: RFR 8191736: replace javah w/ javac in jdk tests

Looks fine. On 21/11/2017 16:09, Jonathan Gibbons wrote: Shura, Looks OK to me, although I'm not normally a Reviewer for AWT tests. -- Jon On 11/21/17 3:58 PM, Alexandre (Shura) Iline wrote: Hi. Please take look on this quick fix of removing remains of javah usages from test/jdk. Bug: