Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

Nice tool. However, I am not sure how toFormattedHexString() and toPrintableString() are useful, seems only for providing a customizable dump format which is, actually, not very customizable. For me, toHexString and fromHexString are of course the most useful methods. As for dump, I can only t

Re: Rationale behind having type variables for Collector's accumulator types in public APIs

Hi Lukas, See this thread: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html Paul. > On May 7, 2018, at 2:00 AM, Lukas Eder wrote: > > Hello, > > I'm currently designing API that I'd like to ke

[PATCH] 8202521: Add overloaded methods of Map#compute, Map#computeIfAbsent, Map#computeIfPresent

Hi Paul, Thank you for the response! I understand I should have discussed this before submitting a patch, and will do so from now on. I would be happy to contribute to fixing some starter bugs, and I'd be very grateful if you are able point me to some! - Jacob

Re: [PATCH] 8202521: Add overloaded methods of Map#compute, Map#computeIfAbsent, Map#computeIfPresent

Hi Jacob, Thanks for looking at this. What you have done looks complete (although it is not necessary on HashTable since it tunnels directly to computeIfAbsent), and the performance evaluation is appreciated. While i have some sympathy with this, having written many such computeIfAbsent calls,

Re: [11] RFR: 8202553: Update FXLauncherTest as part of removing JavaFX from JDK

Hi Kevin, Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8202553 http://cr.openjdk.java.net/~kcr/8202553/webrev.00/ FXLauncherTest.java: 57 private static final String TEST_SRC = System.getProperty("test.src"); Since this test extends TestHelper, it alre

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

> On May 7, 2018, at 11:20 AM, B. Blaser wrote: > > On 7 May 2018 at 14:19, B. Blaser wrote: >> On 6 May 2018 at 18:35, B. Blaser wrote: >>> On 5 May 2018 at 22:26, Kim Barrett wrote: > On May 5, 2018, at 8:03 AM, B. Blaser wrote: > > On 4 May 2018 at 17:42, Alan Bateman wrote:

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

David, Please see inline. — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On May 8, 2018 at 11:44:11 AM, David Lloyd (david.ll...@redhat.com) wrote: I'm not a reviewer, but I would ask: how sure are we that it's OK to use lambdas from here? Is there a chance that the magic boot

Re: JDK 11 RFR of JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec

On Tue, May 8, 2018 at 9:19 AM, joe darcy wrote: > > Maybe > > The unsigned > * right shift operator ({@code >>>}) is omitted, as this operation only > makes sense with a fixed word size. > > > How about > > The unsigned right shift operator ({@code >>>}) is omitted since this > operation only

Re: JDK 11 RFR of JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec

Hi Joe, On May 8, 2018, at 9:19 AM, joe darcy wrote: > On 5/7/2018 10:45 PM, Martin Buchholz wrote: >> […] >> >> The unsigned >> * right shift operator ({@code >>>}) is omitted, as this operation only >> makes sense with a fixed word size. > > How about > > The unsigned right shift operato

Re: JDK 11 RFR of JDK-8202563: BigInteger/BigDecimal not immune to overflow, contrary to spec

On 5/7/2018 10:45 PM, Martin Buchholz wrote: Thanks for doing this - wordsmithing is hard. Maybe The unsigned * right shift operator ({@code >>>}) is omitted, as this operation only makes sense with a fixed word size. How about The unsigned right shift operator ({@code >>>}) is omitted sinc

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

On 08/05/2018 16:43, David Lloyd wrote: : Also, I would be quite surprised if there wasn't a way to get a system property from system code without having to use doPrivileged; that might bear some researching. GetPropertyAction.privilegedGetProperty - there's an example usage in the getMaxCache

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

I'm not a reviewer, but I would ask: how sure are we that it's OK to use lambdas from here? Is there a chance that the magic bootstrap stuff won't yet be initialized at the time when an early thread could exit for whatever reason? Anyway I think using a lambda with forEach is probably overkill in

[11] RFR: 8202553: Update FXLauncherTest as part of removing JavaFX from JDK

Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8202553 http://cr.openjdk.java.net/~kcr/8202553/webrev.00/ This modifies the existing FXLauncherTest as follows: 1. Reverse the check for the presence of the javafx.application.Application class and fail the test if

RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

Hi all, Following the discussion on this a few weeks ago, here’s the first version of the change: http://cr.openjdk.java.net/~tonyp/8202788/webrev.0/ I think the consensus was that it’d be easier if the exit hooks were only available within java.base. Is it enough that I added the functionality

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Hi Jim, I would agree about code points in methods that refer to code points and need a more precise notation.  However, trim() is not one of them and the alternative 0x format is quite acceptable. Would the syntax for raw string literals (not there yet) make the source more readable? Roger

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Roger, You withdrew the comment from the CSR so I assumed that you had changed your mind. Stuart, Sherman and Joe have be pushing the use of codepoints versus char (or ASCII) in new character related comments hence the choice of ‘\u' notation. Unfortunately, unicode preprocessing vs backsl

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Hi Jim, The use of \u005c in the source makes the source code unreadable. The more conventional use of the 0x prefix (i.e. 0x0130) is preferred. Though \u is necessary in some cases, it should be avoided where a more readable alternative is available. Thanks, Roger On 5/8/2018 8:19 AM, Jim L

Re: RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Looks good -Sundar On 08/05/18, 5:49 PM, Jim Laskey wrote: Comment change approved in CSR webrev: http://cr.openjdk.java.net/~jlaskey/8200372/webrev/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8200372 CSR: https://bugs.openjdk.java.net/browse/JDK-8196005

RFR JDK-8200372 - String::trim JavaDoc should clarify meaning of space

Comment change approved in CSR webrev: http://cr.openjdk.java.net/~jlaskey/8200372/webrev/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8200372 CSR: https://bugs.openjdk.java.net/browse/JDK-8196005

Re: RFR: 8202548: Use reservation Object when creating SpeciesData

Thanks Peter, I incorporated your changes and pushed. Sadly missed one of the editorial changes somehow, but I'll make a note to have that fixed next time I touch this. /Claes On 2018-05-07 20:46, Peter Levart wrote: Hi, This looks good, except that comments in method are now obsolete. I

RE: RFR(M): 8202745: Remove hyphens from "out-of-bounds".

Hi David, Thanks for looking at this. > The grammar can be a bit subtle here. IIUC we would say: > "Index %d out of bounds for length %d" > but if we turn it around we'd say: > "out-of-bounds index %d for length %d" Yes, this is the assumption of my edits. > src/hotspot/cpu/ppc/ppc.ad > I'd con

Re: RFR(M): 8202745: Remove hyphens from "out-of-bounds".

On 07/05/18 23:08, John Rose wrote: You_may_ use "out-of-bounds" when it modifies a noun. The form "out-of-bounds" is a compound adjective. It is the compound-adjective form of "out of bounds". See Rule 1 of this page: https://www.grammarbook.com/punctuation/hyphens.asp We should be intern