Re: Review request for JDK-8252124: Restore Dynalink tests

Looks good. Minor comment: not sure if you need to update copyright year on tests - especially because there have been changes like package removal (flat). -Sundar On 21/08/20 1:50 am, Attila Szegedi wrote: Hi folks, long time since I actively popped up here. I’m taking some time to maintai

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

Hi, Mandy On 8/20/20 5:10 PM, Mandy Chung wrote: On 8/19/20 10:14 PM, Yumin Qi wrote: HI, Mandy   Thanks for the review, I took one day off yesterday so just got a detail look of your reply. On 8/19/20 1:30 PM, Mandy Chung wrote: On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks f

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/19/20 10:14 PM, Yumin Qi wrote: HI, Mandy   Thanks for the review, I took one day off yesterday so just got a detail look of your reply. On 8/19/20 1:30 PM, Mandy Chung wrote: On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev at

Re: RFR: JDK-8251988: jpackage --runtime-image fails on mac when using JDK11 based runtime.

Andy, I'd replace 'File.separator' with '/' to make value of 'jpackage.app-path' property platform independent. It would be also good to have a unit test verifying values of the new properties. - Alexey On 8/20/2020 5:44 PM, Andy Herrick wrote: Please review the jpackage fix at [1] to issue

RFR: JDK-8251988: jpackage --runtime-image fails on mac when using JDK11 based runtime.

Please review the jpackage fix at [1] to issue [2]. This fixes the problem loading libjli.dylib as well as  providing some useful generic system properties. /Andy [1] - http://cr.openjdk.java.net/~herrick/8251988/webrev.02/ [2] - ht

Re: Review request for JDK-8251538: Modernize and lint Dynalink code

- Mail original - > De: "Attila Szegedi" > À: "core-libs-dev" > Envoyé: Jeudi 20 Août 2020 22:40:53 > Objet: Review request for JDK-8251538: Modernize and lint Dynalink code > Following up on the previous e-mail, here’s the modernization and linting work > on the existing Dynalink codeba

Re: RFR 8252128: Remove javax.transaction Exception references

Hi Lance, Looks fine. Thanks, Roger On 8/20/20 4:58 PM, Lance Andersen wrote: Hi all, The following patch removes some extraneous references to javax.transaction exceptions and removes a couple of unused fields that represented serialized versions of the exceptions. This was missed in the

Re: RFR 8251989: Hex encoder and decoder utility

Hi Mark, On 8/20/20 3:10 PM, mark.reinh...@oracle.com wrote: 2020/8/19 14:14:56 -0700, roger.ri...@oracle.com: Please review a java.util.Hex API to encode and decode hexadecimal strings to and from byte arrays. JavaDoc: http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.htm

RFR 8252128: Remove javax.transaction Exception references

HI all, The following patch removes some extraneous references to javax.transaction exceptions and removes a couple of unused fields that represented serialized versions of the exceptions. This was missed in the removal of the CORBA and Java EE modules. The webrev can be found at: http://cr

Re: RFR 8251989: Hex encoder and decoder utility

Hi Max, The idea was to keep all the Hex functions together. Its a bit of a mismatch with StringBuilder; StringBuilder doesn't deal with arrays and is pretty bulky as it is. And StringBuilder doesn't have a corresponding parse companion; the string to byte[] array functions are needed to. Tr

Review request for JDK-8251538: Modernize and lint Dynalink code

Following up on the previous e-mail, here’s the modernization and linting work on the existing Dynalink codebase: Please review JDK-8251538 "Modernize and lint Dynalink code" at for The

Review request for JDK-8252124: Restore Dynalink tests

Hi folks, long time since I actively popped up here. I’m taking some time to maintain Dynalink, eyeing Java 16 for the changes. Since the nashorn-dev list is (presumably? I haven’t bother checking) defunct, I asked around and Sundar suggested core-libs-dev is the right list to post review reque

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

Hi Christoph, Looks good. Note that Claes added the cases for Object.class and int.class to maximize the performance of those common cases. I'll sponsor the change. Thanks, Roger On 8/20/20 2:01 PM, Christoph Dreis wrote: Hi Roger, thanks for taking a look! Though I wonder if performs di

Re: RFR 8251989: Hex encoder and decoder utility

2020/8/19 14:14:56 -0700, roger.ri...@oracle.com: > Please review a java.util.Hex API to encode and decode hexadecimal > strings to and from byte arrays. > > JavaDoc: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html This mostly looks good -- it’ll be nice to have a s

Re: RFR 8251989: Hex encoder and decoder utility

How about StringBuilder::appendHex instead of Encoder::encode(SB, byte[])? Then we don’t need to break the chain when appending many different things to a StringBuilder. Also, are prefix and suffix really useful? One can easily add them. Thanks, Max > On Aug 19, 2020, at 5:14 PM, Roger Riggs

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

On 8/20/20 11:01 AM, Christoph Dreis wrote: === PATCH === --- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java Thu Aug 13 09:33:28 2020 -0700 +++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java Thu Aug 20 19:44:57 202

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

Hi Roger, thanks for taking a look! > Though I wonder if performs differently than just calling > t.descriptorString()? Seems pretty much to be the same. The difference of 1 ns for the primitive case is a bit weird, but I guess at this levels it's also possible to have fluctuations here and t

RFR: JDK-8252113: Move jfr man page into jfr module

Hi All, Should jfr.1 be moved from java.base to the jdk.jfr module source directory, as indicated here? Webrev: http://cr.openjdk.java.net/~afarley/8252113/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8252113 It seems to me that it should, as man pages should be with their code (as a

Re: RFR 8251989: Hex encoder and decoder utility

Hi Raffaello, Will do, an oversight in updating the example. Thanks, Roger On 8/20/20 12:46 PM, Raffaello Giulietti wrote: Hi Roger, in the examples in the javadoc you might want to correct the first argument to Hex.encoder and Hex.decoder to "," to be consistent with the narrative. Gre

RFR 8251989: Hex encoder and decoder utility

Hi Roger, in the examples in the javadoc you might want to correct the first argument to Hex.encoder and Hex.decoder to "," to be consistent with the narrative. Greetings Raffaello JavaDoc: http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

Re: RFR 8251989: Hex encoder and decoder utility

Hi Chris, Thanks for the comments, I'll make the updates suggested. Roger On 8/20/20 11:33 AM, Chris Hegarty wrote: On 19 Aug 2020, at 22:14, Roger Riggs wrote: .. JavaDoc: http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html I like it Roger, very nice. A few minor c

Re: RFR 8251989: Hex encoder and decoder utility

> On 19 Aug 2020, at 22:14, Roger Riggs wrote: > > .. > JavaDoc: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html I like it Roger, very nice. A few minor comments/quibbles: Hex: - "Utilities to encode bytes to hex strings and decode hex strings to bytes.” - This

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

Hi Chris, Inlining and simplifying unparseSig(cl, sb) seems straightforward. Though I wonder if performs differently than just calling t.descriptorString()? The first action of Class.descriptorString is to check for primitives and return the basicTypeString and if not a primitive it calls C

[PATCH] continuation of JDK-6736490

Hello, in June I sent a letter regarding clean-ups of unnecessary explicit initialization of volatile variables [1]. Original mail caused some discussion regarding whether clean-up is safe as of JMM. It turned out that Aleksey Shipilev tried to find conter-example against removal of explicit i