Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Naoto, Thank you for your reply. I fully agree to your reluctance or inhibition to change the regex part just along with the jar manifest. On the other hand, i'm quite confident that all invocations of Grapheme.nextBoundary with my previous patch start matching at the previous boundary and there

Re: RFR: 8240725: Some functions might not work with CJK character

Thanks Sato-san! Yasumasa On 2020/03/11 12:27, naoto.s...@oracle.com wrote: Looks good to me. Thanks for the fix! Naoto On 3/10/20 5:39 PM, Yasumasa Suenaga wrote: Hi Sato-san, Thanks for your comment. I uploaded new webrev:    http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/

Re: RFR: 8240725: Some functions might not work with CJK character

Looks good to me. Thanks for the fix! Naoto On 3/10/20 5:39 PM, Yasumasa Suenaga wrote: Hi Sato-san, Thanks for your comment. I uploaded new webrev:   http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/ On 2020/03/11 2:08, naoto.s...@oracle.com wrote: Hi Suenaga-san, Thank you for

RE: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

> -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Tuesday, March 10, 2020 3:53 PM > To: Yangfei (Felix) ; core-libs-dev@openjdk.java.net > Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible > between builds > > On 10/03/2020 02:54, Yangfe

Re: RFR: 8240725: Some functions might not work with CJK character

Hi Sato-san, Thanks for your comment. I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.03/ On 2020/03/11 2:08, naoto.s...@oracle.com wrote: Hi Suenaga-san, Thank you for the update. I think your changes to the return values of MultiByteToWideChar look good. T

Re: RFR: 8240725: Some functions might not work with CJK character

Ah, thanks Martin. Never mind about the comment wrt free(NULL) then. Naoto On 3/10/20 11:30 AM, Martin Buchholz wrote: On Tue, Mar 10, 2020 at 10:08 AM > wrote: Then I noticed (should have noticed in the first place, sorry) that the error handling in c

Re: Review Request: JDK-8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL

This looks good to me Mandy. Thanks, -Chris. > On 10 Mar 2020, at 18:27, Mandy Chung wrote: > > Hi Chris, > > Below is the revised patch per your suggestion. I made some minor fixes in > the method name shown in the "Access modes" section as well. > > Mandy > > diff --git a/src/java.base/s

Re: RFR: 8240725: Some functions might not work with CJK character

On Tue, Mar 10, 2020 at 10:08 AM wrote: > > Then I noticed (should have noticed in the first place, sorry) that the > error handling in canonicalize_md.c is incorrect (unrelated to your > change). All error cases "goto finish" which would end up "free(NULL)" > in some cases, e.g. > FYI free(NUL

Review Request: JDK-8240242: improve the javadoc for Lookup::dropLookupModes w.r.t. dropping UNCONDITIONAL

Hi Chris, Below is the revised patch per your suggestion.  I made some minor fixes in the method name shown in the "Access modes" section as well. Mandy diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Philipp, The reason that the current implementation of Grapheme boundary check does it is that, some rules require information before the boundary, i.e. the rule GB12 in Unicode Segmentation [1] reads: "do not break between regional indicator (RI) symbols if there is an odd number of RI c

Re: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

On 10/03/2020 15:10, Martin Buchholz wrote: Aside: if all you want to do is make a use of HashMap more reproducible, the standard reaction is s/HashMap/LinkedHashMap/g Yes, if the insertion order is reproducible. We've had several issues with trying to get to reproducible builds, I suspect this

Re: RFR: 8240725: Some functions might not work with CJK character

Hi Suenaga-san, Thank you for the update. I think your changes to the return values of MultiByteToWideChar look good. Then I noticed (should have noticed in the first place, sorry) that the error handling in canonicalize_md.c is incorrect (unrelated to your change). All error cases "goto fin

Re: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

Aside: if all you want to do is make a use of HashMap more reproducible, the standard reaction is s/HashMap/LinkedHashMap/g On Tue, Mar 10, 2020 at 12:53 AM Alan Bateman wrote: > On 10/03/2020 02:54, Yangfei (Felix) wrote: > > Hi, > > > >We found module-info.class in java.base.jmod is not al

Re: JDK14 spec query : MethodHandles:dropLookupMode(int)

Mandy, > On 9 Mar 2020, at 18:55, Mandy Chung wrote: > > ... > > Here is the spec clarification I am thinking of that may explain why the > focus is not whether MODULE bit is set or not. > > @@ -1524,14 +1524,20 @@ > * Creates a lookup on the same lookup class which this lookup obje

Re: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds

On 10/03/2020 02:54, Yangfei (Felix) wrote: Hi, We found module-info.class in java.base.jmod is not always consistent across different builds. The ModuleHashes attribute in this module-info.class is not reproducible between builds. Patch fixes the issue by using TreeMap instead of Has

Re: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes

Hi Naoto and everyone, When I tried the regular expression approach you proposed which really looks delightful, ValueUtf8Coding test ran into a timeout, which is why I changed Pattern and Grapheme classes to start the loop in nextBoundary to start at the offset off rather than at the beginning of t