Re: [15] RFR: 8239480: Support for CLDR version 37

On 5/20/2020 7:06 PM, naoto.s...@oracle.com wrote: Hi Joe, thanks again! No problem. The license file "unicode-license.txt" is actually included in the version 37 artifact: https://github.com/unicode-org/cldr/blob/release-37/unicode-license.txt The changeset uses the file as is, so I

Re: [15] RFR: 8239480: Support for CLDR version 37

Hi Joe, thanks again! The license file "unicode-license.txt" is actually included in the version 37 artifact: https://github.com/unicode-org/cldr/blob/release-37/unicode-license.txt The changeset uses the file as is, so I believe it is OK. Naoto On 5/20/20 6:51 PM, Joe Wang wrote: Looks

Re: [15] RFR: 8239480: Support for CLDR version 37

Looks good to me. A minor comment: in the license files, Terms of Use lost its original format (e.g. headings and numbering), lines are also super long. But I think we've seen them in the previous update, it's up to you whether you'd want to reformat

Re: [15] RFR: 8245241: Incorrect locale provider preference is not logged

Hi Naoto, Thanks for the explanation. I agree on the needs for maintaining backward compatibility.  The patch looks good me then. Best, Joe On 5/20/2020 4:49 PM, naoto.s...@oracle.com wrote: Hi Joe, thanks for the review. On 5/20/20 4:10 PM, Joe Wang wrote: Hi Naoto, I don't seem to see

Re: [15] RFR: 8245241: Incorrect locale provider preference is not logged

Hi Joe, thanks for the review. On 5/20/20 4:10 PM, Joe Wang wrote: Hi Naoto, I don't seem to see the DateFormat class or the getDateInstance methods specify how errors may be handled (or logged). Is that stated somewhere else? Description of the system property "java.locale.providers" is

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Vicente, On 21/05/2020 1:40 am, Vicente Romero wrote: Hi David, src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 +  * Returns an array containing {@code

Re: [15] RFR: 8245241: Incorrect locale provider preference is not logged

Hi Naoto, I don't seem to see the DateFormat class or the getDateInstance methods specify how errors may be handled (or logged). Is that stated somewhere else?  In other cases, I see that you've changed it to throw ServiceConfigurationError, that looks to me may be better than a log as a

Re: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

On 5/20/20 10:29 AM, Paul Sandoz wrote: Thanks, tier3 it is! Great, now Vector API tests could be automatically run with default HS flags as part of tier3 testing in mach5. I am curious about how those tests can be co-opted for HS tiers. Can you share details on the panama-dev thread? I

[15] RFR: 8239480: Support for CLDR version 37

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8239480 The proposed changeset, and the release note draft are located at: https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8243581 This updates the

Re: BigInteger.squareToLen() can be wrong (when called directly)

Hi. >I filed https://bugs.openjdk.java.net/browse/JDK-8245038 to track this. Can't seem to comment the bug so I post here. >>The core issue is in implMulAdd(), where 'offset' is set to >>"out.length-offset - 1" >>instead of >>"zlen - offset - 1" There is another place that needs a fix for pure

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Biasing towards ordering is covered in https://bugs.openjdk.java.net/browse/JDK-8181146 (read the markmail thread link in the ticket) and some of those changes worked there way into

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Remi, Thank you for reviewing the ASM changes. Harold On 5/19/2020 4:41 AM, Remi Forax wrote: - Mail original - De: "David Holmes" À: "Harold David Seigel" , "hotspot-runtime-dev" , "amber-dev" , "core-libs-dev" , "serviceability-dev" Envoyé: Mardi 19 Mai 2020 07:26:38 Objet:

Re: Optimize (Linked-)HashMap lookup when backing array is null

I don't have a good intuition either, but this optimization feels like a natural companion to the optimization to not allocate backing arrays for empty maps in the first place - which seems to be a rather common occurrence[1]. And since we'll not call hashCode() when the map is empty, the gain

Re: Optimize (Linked-)HashMap lookup when backing array is null

No strong opinion either way, but ... Generally we try to avoid special case code just for performance. The value depends on how rare lookups on empty maps are; I don't have a good intuition on that. On Wed, May 20, 2020 at 12:11 PM Claes Redestad wrote: > > Hi, > > seems acceptable to me, too.

Re: Optimize (Linked-)HashMap lookup when backing array is null

Hi, seems acceptable to me, too. I'd be happy to sponsor this, but just starting a long weekend here so might not have time before start of next week. /Claes On 2020-05-19 22:21, Roger Riggs wrote: Hi, Right, its only in the case of removing the node because the new value was null.

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Do you believe that Set.equals() should behave this way on SortedSets? > On May 20, 2020, at 11:23 AM, Jason Mehrens wrote: > > public class SetEquals { > >public static void main(String[] args) { >Comparator cc = String.CASE_INSENSITIVE_ORDER; >Set s1 = new TreeSet<>(cc);

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Alan, This contains that and that contains this at least avoids calling size which could be expensive or ephemeral at the AbstractSet level. Using the iterators you can at least do a final check to see there are no more elements to walk. Biasing towards ordering could pay off for things

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

> On 20 May 2020, at 15:01, Maurizio Cimadamore > wrote: > > Another very small iteration which fixes a gap in the javadoc specification > for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > >

[15] RFR: 8245241: Incorrect locale provider preference is not logged

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8245241 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ Incorrect user-provided provider preference is supposed to be logged. However it is not so

Re: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Thanks, tier3 it is! I am curious about how those tests can be co-opted for HS tiers. Can you share details on the panama-dev thread? Paul. diff -r a606409980d6 test/jdk/TEST.groups --- a/test/jdk/TEST.groups Fri May 15 17:23:27 2020 -0700 +++ b/test/jdk/TEST.groups Wed May 20

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Vicente, On 5/20/20 8:40 AM, Vicente Romero wrote: Hi David, src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 Adding to David's comment w.r.t. @throws IAE:

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

+1 Paul. > On May 20, 2020, at 7:01 AM, Maurizio Cimadamore > wrote: > > Another very small iteration which fixes a gap in the javadoc specification > for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > >

Re: RFR: JDK-8225056 VM support for sealed classes

Hi David, src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 +  * Returns an array containing {@code ClassDesc} objects representing all the +  * permitted

Re: RFR: 8215401: Add isEmpty default method to CharSequence

On 2020-05-20 16:10, Alan Bateman wrote: On 19/05/2020 20:35, Claes Redestad wrote: Hi Jason, I guess overriding and marking the CharBuffer method final for consistency wouldn't hurt. Except I probably need to pass this through another CSR review. Also added test cases for char[] and

Re: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted

Disregard. I have two bugs against String.java and overlapped the email. > On May 20, 2020, at 8:54 AM, Jim Laskey wrote: > > All call for aid response to a comment on the CSR from Joe. > >> I suggesting having some explicit statement about the line count in addition >> to the number of line

Re: RFR: 8215401: Add isEmpty default method to CharSequence

On 19/05/2020 20:35, Claes Redestad wrote: Hi Jason, I guess overriding and marking the CharBuffer method final for consistency wouldn't hurt. Except I probably need to pass this through another CSR review. Also added test cases for char[] and String-based CharBuffers:

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Another very small iteration which fixes a gap in the javadoc specification for MemorySegment::toArray (thanks Chris!) Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/ Cheers Maurizio On

Re: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted

All call for aid response to a comment on the CSR from Joe. > I suggesting having some explicit statement about the line count in addition > to the number of line terminators. That is the crux of the skirting around. Line count can mean two things depending on whether lines are interpreted as