Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On 16/02/2018 20:35, yumin qi wrote: : Updated bug,  and update webrev at same link: http://cr.openjdk.java.net/~minqi/8194154/webrev1/ I think this version is good to go. -Alan

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 16/02/2018 21:56, Stuart Marks wrote: : Seems like an argument that this function is in the wrong location. (Not joking.) I think CharBuffer.toString() is actually quite obscure. I note that most of the Buffer classes have toString() methods that report the *status* of the buffer, e.g.

Re: RFR: 8197594 - String and character repeat

I really can’t see the value of more than one method. If we need other forms they should be for constructing strings not repeating strings. Sent from my MacBook Wheel > On Feb 16, 2018, at 6:12 PM, Xueming Shen wrote: > >> On 2/16/18, 5:13 PM, Stuart Marks wrote: >> Let me put in an argument

Re: RFR: 8197594 - String and character repeat

On 2/16/18, 5:13 PM, Stuart Marks wrote: Let me put in an argument for handling code points: 3. public static String repeat(final int codepoint, final int count) Most of the String and Character API handles code points on an equal footing with chars. I think this is important, as over time U

Re: RFR: 8197594 - String and character repeat

Disagree. On #3, most of the time the char being repeated is already a literal. So just make it a string. On #2, better to aim for string.ofCodePoint(int) and compose w repeat. Down to one method again :) Sent from my MacBook Wheel > On Feb 16, 2018, at 5:13 PM, Stuart Marks wrote: >

Re: RFR: 8197594 - String and character repeat

Let me put in an argument for handling code points: 3. public static String repeat(final int codepoint, final int count) Most of the String and Character API handles code points on an equal footing with chars. I think this is important, as over time Unicode is continuing to add supplementary

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 02/16/2018 03:04 PM, Richard Warburton wrote: Hi gents, public String(ByteBuffer bytes, Charset cs); public String(ByteBuffer bytes, String csname); I think these constructors make good sense. They avoid an extra copy to an intermediate byte[]. One issue (also ment

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Hi gents, public String(ByteBuffer bytes, Charset cs); >> public String(ByteBuffer bytes, String csname); >> > > I think these constructors make good sense. They avoid an extra copy to an > intermediate byte[]. > > One issue (also mentioned by Stephen Colebourne) is whether we need the > csname ov

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Hi gents, Thanks Sherman for taking up the bat on this one - most appreciated. These four methods encode as many characters as possible into the destination byte[] or buffer but don't give any indication that the destination didn't have enough space to encode the entire string. I thus >

RFR 8189330 Cleanup FileDescriptor implementation

Please review a cleanup and refactoring of FileDescriptor.java. The Unix and Windows versions are merged to ease maintenance remove replicated code The FileCleanable class is extracted and SocketCleanable is updated. Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-fd-cleanup-8189330/ Issue

Re: [JDK-6341887] Patch: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

Also available in more readable form at: https://github.com/dmlloyd/openjdk/commit/becd36e852e55a29a4685577453944552c817b66 On Fri, Feb 16, 2018 at 4:13 PM, David Lloyd wrote: > It would be convenient to be able to inflate/deflate a direct or heap > byte buffer without having to copy it throu

[JDK-6341887] Patch: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

It would be convenient to be able to inflate/deflate a direct or heap byte buffer without having to copy it through an array first. For my Friday mini-project this week, I've decided to take a crack at this. The attached patch is the result. Would anyone be interested in reviewing and maybe spons

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 2/16/18 6:14 AM, Alan Bateman wrote: On 15/02/2018 21:55, Stuart Marks wrote: I'd also suggest adding a CharBuffer constructor:     public String(CharBuffer cbuf) This would be semantically equivalent to     public String(char[] value, int offset, int count) except using the chars from th

Re: [11] RFR: JDK-8198228: Spec clarification: j.u.Locale.getDisplayName()

Looks fine. Roger On 2/16/2018 2:22 PM, naoto.s...@oracle.com wrote: Hello, Please review this small doc-only fix for this issue: https://bugs.openjdk.java.net/browse/JDK-8198228 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8198228/webrev.00/ It is just to clari

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On Fri, Feb 16, 2018 at 3:52 AM, Alan Bateman wrote: > On 15/02/2018 20:28, yumin qi wrote: > >> : >> Since the property string contains non-normalized characters, it >> crashed in native canonicalize. >> I believe user.dir from the system is normalized, so it is OK but >> after it is cha

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Hi Adam, From reading the thread i cannot tell if this is part of a wider solution including some yet to be proposed HotSpot changes. As is i would be resistant to adding such standalone internal wrapper methods to Unsafe that have no apparent benefit within the OpenJDK itself since it's a mai

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/16/18 11:11 AM, Martin Buchholz wrote: The small optimization to avoid checking for "already finalized" could be done in a follow-up. Before working on Finalizer.java I was not really aware of the global "unfinalized" data structure with a non-scalable lock.  This could probably be

[11] RFR: JDK-8198228: Spec clarification: j.u.Locale.getDisplayName()

Hello, Please review this small doc-only fix for this issue: https://bugs.openjdk.java.net/browse/JDK-8198228 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8198228/webrev.00/ It is just to clarify the field separator in locale display names. Corresponding CSR (81982

Re: [1] RFR(XXS): 8197927: Can't set mandatory 'java.vendor.version' property to empty string

2018/2/16 10:59:57 -0800, volker.simo...@gmail.com: > On Fri, Feb 16, 2018 at 7:02 PM, mark.reinh...@oracle.com wrote: >> Of course it's possible. The specification need merely say that >> `java.vendor.version` is a standard system property that may, or may >> not, have a value. (Or, if you like,

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On Fri, Feb 16, 2018 at 10:26 AM, mandy chung wrote: > > > On 2/16/18 6:52 AM, Peter Levart wrote: > > I think that the following now never applies (in Finalizer) since > ReferenceQueue never returns the same Reference object more than once: > > 71 if (this.next == this) // alr

Re: [1] RFR(XXS): 8197927: Can't set mandatory 'java.vendor.version' property to empty string

On Fri, Feb 16, 2018 at 7:02 PM, wrote: > 2018/2/14 8:04:15 -0800, volker.simo...@gmail.com: > > On Wed, Feb 14, 2018 at 4:26 PM, mark.reinh...@oracle.com wrote: > >> This is a bug in the specification, not the implementation. As I just > >> wrote in a comment on 8197927: > >> > >> JEP 322 expre

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/16/18 6:52 AM, Peter Levart wrote: I think that the following now never applies (in Finalizer) since ReferenceQueue never returns the same Reference object more than once:   71 if (this.next == this)  // already finalized   72 return; You could change it

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/16/18 4:54 AM, David Holmes wrote: On 16/02/2018 10:12 PM, Alan Bateman wrote: On 16/02/2018 04:09, mandy chung wrote: Merged.  New version: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/ Good to see this change. One comment on Runtime.exec is that the 3rd paragra

Re: [1] RFR(XXS): 8197927: Can't set mandatory 'java.vendor.version' property to empty string

2018/2/14 8:04:15 -0800, volker.simo...@gmail.com: > On Wed, Feb 14, 2018 at 4:26 PM, mark.reinh...@oracle.com wrote: >> This is a bug in the specification, not the implementation. As I just >> wrote in a comment on 8197927: >> >> JEP 322 expresses the intended behavior: If `--with-vendor-version

[11] RFR: (JAXP) 8038043: Xerces Update: XInclude update

Hi, Please, help to review the update of XInclude related classes from the Apache Xerces 2.11.0 source. JBS:     https://bugs.openjdk.java.net/browse/JDK-8038043 The webrev:     http://cr.openjdk.java.net/~aefimov/8038043/11/00/ New regression test has been added to check the updated reporting

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 15/02/2018 21:55, Stuart Marks wrote: : I'd also suggest adding a CharBuffer constructor:     public String(CharBuffer cbuf) This would be semantically equivalent to     public String(char[] value, int offset, int count) except using the chars from the CharBuffer between the buffer's pos

Re: [11] RFR JDK-8190904: Incorrect currency instance returned by java.util.Currency.getInstance()

Looks good to me. Naoto On 2/16/18 3:50 AM, Nishit Jain wrote: Hi, Please review the fix for JDK-8190904. Bug: https://bugs.openjdk.java.net/browse/JDK-8190904 Webrev: http://cr.openjdk.java.net/~nishjain/8190904/webrev.07/ CSR: https://bugs.openjdk.java.net/browse/JDK-8196835 Issue: The cur

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Mandy, > On 15 Feb 2018, at 20:10, mandy chung wrote: > > Hi Robin, > > Do you want a shutdown event for every call to Runtime::exit regardless where > it is in the shutdown sequence? or do you expect to get an event of the > first thread calling JVM_Halt? or the first thread starting th

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Roger, > On 15 Feb 2018, at 17:00, Roger Riggs wrote: > > Hi Robin, > > Looks fine to me. Thanks for reviewing! > (How is this tested?, Normal, exceptional, etc.) The tests are part of the (currently closed) JFR tests. Best regards, Robin > > Thanks, Roger > > > On 2/15/2018 8:35 AM

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 2/16/18, 5:58 AM, Ulf Zibis wrote: Hi, what is the difference of: - class StringCoding - class StringCoder - class StringCoding.StringDecoder - class StringCoding.StringEncoder Why we need so much variants of redundant code? I think it would be useful to have some explanation in the javadoc

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 02/16/2018 05:09 AM, mandy chung wrote: On 2/15/18 7:29 PM, Martin Buchholz wrote: This also changes the handling of (undeprecated) method runFinalization and that's obviously related but could be a separate changeset. I agree I should separate the runFinalization change.  I

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Hi, what is the difference of: - class StringCoding - class StringCoder - class StringCoding.StringDecoder - class StringCoding.StringEncoder Why we need so much variants of redundant code? I think it would be useful to have some explanation in the javadoc. Missing indentation in StringCoder.

Re: RFR: 8197594 - String and character repeat

We’re going with the one instance method (Louis clinched it.) with recommended enhancements and not touching CharSequence. Working it up now. — Jim > On Feb 16, 2018, at 7:46 AM, Alan Bateman wrote: > > On 15/02/2018 17:20, Jim Laskey wrote: >> This is a pre-CSR code review [1] for String rep

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 16/02/2018 10:12 PM, Alan Bateman wrote: On 16/02/2018 04:09, mandy chung wrote: Merged.  New version: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/ Good to see this change. One comment on Runtime.exec is that the 3rd paragraph of the updated spec is difficult to rea

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 16/02/2018 04:09, mandy chung wrote: Merged.  New version: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/ Good to see this change. One comment on Runtime.exec is that the 3rd paragraph of the updated spec is difficult to read (too many "ifs" and "thens"). What would yo

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On 15/02/2018 20:28, yumin qi wrote: :     Since the property string contains non-normalized characters, it crashed in native canonicalize.     I believe user.dir from the system is normalized, so it is OK but after it is changed like "/home/a/b/c/", it crashed.     Now with using cached "use

[11] RFR JDK-8190904: Incorrect currency instance returned by java.util.Currency.getInstance()

Hi, Please review the fix for JDK-8190904. Bug: https://bugs.openjdk.java.net/browse/JDK-8190904 Webrev: http://cr.openjdk.java.net/~nishjain/8190904/webrev.07/ CSR: https://bugs.openjdk.java.net/browse/JDK-8196835 Issue: The currency superseding feature gives the possibility of allowing two s

Re: RFR: 8197594 - String and character repeat

On 15/02/2018 21:59, Joseph D. Darcy wrote: : My general recommendation if the code review and CSR review are to be serialized is to estimate which one is more likely to generate feedback that might modify the proposal and run though that process first. Since there has already been feedback l

Re: RFR: 8197594 - String and character repeat

On 15/02/2018 17:20, Jim Laskey wrote: This is a pre-CSR code review [1] for String repeat methods (Enhancement). The proposal is to introduce four new methods; 1. public String repeat(final int count) 2. public static String repeat(final char ch, final int count) 3. public static String repeat

Re: RFR: 8197594 - String and character repeat

On 15 February 2018 at 20:52, Louis Wasserman wrote: > Based on this data, I'd recommend providing one and only one method of this > type: String.repeat(int). Only adding the one instance method seems like the best plan in this case. Stephen