Re: trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

Pushed: https://hg.openjdk.java.net/jdk/jdk/rev/3a3c806aff1f Mandy On 4/24/20 9:17 AM, Mandy Chung wrote: Yes any change requires a JBS issue. I can sponsor this trivial fix. Mandy On 4/24/20 5:15 AM, Raffaello Giulietti wrote: Not sure if this requires an entry in the JBS... Greetings

Re: RFR: 8243469: Lazily encode name in ZipFile.getEntryPos

On 2020-04-24 20:07, Lance Andersen wrote: Hi Claes, Thank you for continuing to improve the performance in this part of java.util.zip.  The changes I think look pretty good. Best Lance Thanks for the review, Lance! Hopefully a few more improvements to come.. /Claes

Re: RFR: 8243469: Lazily encode name in ZipFile.getEntryPos

Hi Volker, On 2020-04-24 20:37, Volker Simonis wrote: On Thu, Apr 23, 2020 at 2:35 PM Claes Redestad wrote: Hi, current implementation of ZipFile.getEntryPos takes the encoded byte[] of the String we're looking up. Which means when looking up entries across multiple jar files, we allocate

Re: RFR: 8243469: Lazily encode name in ZipFile.getEntryPos

On Thu, Apr 23, 2020 at 2:35 PM Claes Redestad wrote: > > Hi, > > current implementation of ZipFile.getEntryPos takes the encoded byte[] > of the String we're looking up. Which means when looking up entries > across multiple jar files, we allocate the byte[] over and over for each > jar file

Re: RFR: 8243469: Lazily encode name in ZipFile.getEntryPos

Hi Claes, Thank you for continuing to improve the performance in this part of java.util.zip. The changes I think look pretty good. Best Lance > On Apr 23, 2020, at 8:34 AM, Claes Redestad wrote: > > Hi, > > current implementation of ZipFile.getEntryPos takes the encoded byte[] > of the

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

On 24/04/2020 17:38, Paul Sandoz wrote: On Apr 23, 2020, at 5:45 PM, Maurizio Cimadamore wrote: On 24/04/2020 01:35, Paul Sandoz wrote: Hi, Looks good. I have seen almost all of this in reviews on panama-dev hence the lack of substantial comments here. I suspect we are not gonna need

Re: RFR: JDK-8236129: Exe installers have wrong properties

looks good /Andy On 4/23/2020 5:34 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Implement rebranding of exe installers produced by jpackage. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8236129 [2] http://cr.openjdk.java.net/~asemenyuk/8236129/webrev.00

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

> On Apr 23, 2020, at 5:45 PM, Maurizio Cimadamore > wrote: > > > On 24/04/2020 01:35, Paul Sandoz wrote: >> Hi, >> >> Looks good. I have seen almost all of this in reviews on panama-dev hence >> the lack of substantial comments here. >> >> I suspect we are not gonna need the drop

Re: trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

Hi Mandy, OK, I'll file a record in the JBS. Thanks for sponsoring Raffaello On 2020-04-24 18:17, Mandy Chung wrote: Yes any change requires a JBS issue. I can sponsor this trivial fix. Mandy On 4/24/20 5:15 AM, Raffaello Giulietti wrote: Not sure if this requires an entry in the JBS...

Re: trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

Yes any change requires a JBS issue. I can sponsor this trivial fix. Mandy On 4/24/20 5:15 AM, Raffaello Giulietti wrote: Not sure if this requires an entry in the JBS... Greetings Raffaello diff -r 70c2239696ae src/java.base/share/classes/java/lang/invoke/MethodHandles.java ---

Re: RFR 15: 8243010: Test support: Customizable Hex Printer

Hi Roger, On 23/04/2020 19:46, Roger Riggs wrote: A review would be appreciated. Ship it! cheers, -- daniel

trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

Not sure if this requires an entry in the JBS... Greetings Raffaello diff -r 70c2239696ae src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Apr 24 16:12:53 2020 +0530 +++

Re: RFR(S): 8241638: launcher time metrics alway report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail)

Dear all, As Lin mentioned, I found the copyright info is not updated, so I prepared a patch to fix this. Lin helps me to build an issue in the jdk bug system. Would you help me to review this patch? Thank you very much. Patch link: https://cr.openjdk.java.net/~lzang/BuddyLiao/launcher/webrev/

Re: RFR: 8243453: Option --describe-module failed with non-ASCII module name under non-UTF8 environment

On 24/04/2020 09:33, Toshio 5 Nakamura wrote: Hi all, Please review this fix. Also, I'd like to ask a sponsor of the fix, since I'm not a committer. Issue: https://bugs.openjdk.java.net/browse/JDK-8243453 Webrev: http://cr.openjdk.java.net/~tnakamura/8243453/webrev.00/ Under Windows Japanese

RFR: 8243453: Option --describe-module failed with non-ASCII module name under non-UTF8 environment

Hi all, Please review this fix. Also, I'd like to ask a sponsor of the fix, since I'm not a committer. Issue: https://bugs.openjdk.java.net/browse/JDK-8243453 Webrev: http://cr.openjdk.java.net/~tnakamura/8243453/webrev.00/ Under Windows Japanese or Chinese, encoding of command line option

Re: RFR 15 8243099: Adding ADQ support to JDK

Hi Vladimir, In LinuxSocketOptions.c we have lot's of duplicate code, can you please reuse "socketOptionSupported" & "handleError" as follows, this we remove lot's of duplicate code. Thanks, Vyom diff -r b6b4506a7827 src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c ---