RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Sandhya Thanks very much for your help. Regards, Yang -Original Message- From: Viswanathan, Sandhya Sent: Wednesday, July 1, 2020 2:57 AM To: Yang Zhang ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net;

Re: RFR: 824850: [macos] App created with jpackage on Mac fails with error -10810

Looks good. - Alexey On 7/2/2020 6:53 PM, Andy Herrick wrote: Please review jpackage fix for issue [1] at [2]. The class path was no longer set correctly when jars are in a sub-directory of the input dir. /Andy [1] - https://bugs.openjdk.java.net/browse/JDK-8248501 [2] -

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hiding is a misleading characterization. It’s about reducing the API surface of this feature for reasons previously mentioned. I am reluctant to impose ObjIntConsumer vs. IntObjConsumer on developers. Paul. > On Jul 2, 2020, at 12:36 PM, fo...@univ-mlv.fr wrote: > > > The rational is that

Re: RFR: 824850: [macos] App created with jpackage on Mac fails with error -10810

Hi Andy, Looks good. Thanks, Alexander On 7/2/2020 3:53 PM, Andy Herrick wrote: Please review jpackage fix for issue [1] at [2]. The class path was no longer set correctly when jars are in a sub-directory of the input dir. /Andy [1] - https://bugs.openjdk.java.net/browse/JDK-8248501 [2]

RFR: 824850: [macos] App created with jpackage on Mac fails with error -10810

Please review jpackage fix for issue [1] at [2]. The class path was no longer set correctly when jars are in a sub-directory of the input dir. /Andy [1] - https://bugs.openjdk.java.net/browse/JDK-8248501 [2] - http://cr.openjdk.java.net/~herrick/8248501/webrev.01/

request for review JDK-8242935

Hi all, please review the following changeset: http://cr.openjdk.java.net/~iignatyev/isipka/8242935/webrev.00/ for the JBS issue https://bugs.openjdk.java.net/browse/JDK-8242935 which replaces Nashorn scripting engine in a service reload test with services defined via classpath (Pear) and via

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

> De: "Paul Sandoz" > À: "Remi Forax" > Cc: "Brian Goetz" , "Julia Boes" > , "core-libs-dev" , > "Patrick Concannon" > Envoyé: Jeudi 2 Juillet 2020 19:46:22 > Objet: Re: RFR[8238286]: 'Add new flatMap stream operation that is more > amenable > to pushing’ > Hi Remi, > This was my suggestion

Re: request for review JDK-8211290

Hi all, thank you for the review, I updated the code and run the test. best regards, On 30/06/2020 23:15, Lance Andersen wrote: Hi Ivan, Looks fine to me also outside of the one extra line that Roger caught. Best Lance On Jun 30, 2020, at 8:38 AM, Ivan Sipka >

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

On 6/24/20 2:56 PM, Daniel Fuchs wrote: The JNDI/LDAP part looks mostly good. You will need someone from the security libs to review the security lib part of the changes. I have previously reviewed it but I would like to give it another once over. Max should also review the final version as

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Remi, This was my suggestion not Brian’s. I proposed to place these interfaces in the current location, likely to be renamed in accordance with the operation name, when that settles. The rational is that they will fade away in unison with Int/*/Stream when generic specialization becomes

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Brian, I understand that adding new functional interfaces has a cost and when you know that generics over primitive types are around the corner, it starts to be an issue, but the compromise to put them in another place hoping that people will not find them is not very appealing, to say the

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Remi, Well spotted on the bad link. I’ve updated that now. http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ As for the placement of the new FIs, it was decided that once we can use primitive types in

Re: contributing to JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

Hi Raffaello, There is way more code changed here than is needed to fix the bug. General enhancement should be separated from bug fixes. It makes it easier to review to see the bug was fixed and easier to separately review other code to see that there are no unexpected changes. If some of the

Re: RFR 8245302: Upgrade LogRecord to support long thread ids and remove its usage of ThreadLocal

Hi Rahul, The updates to the readObject API documentation look good to me. Thanks for adding the missing @Serial annotations! best regards, -- daniel On 02/07/2020 12:35, Rahul Yadav wrote: Hello, I have added comments @Serial based on csr feedback for read/writeObject methods. webrev:

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Tagir, Thank you for your input. However, we feel that this approach may add more complexity than is needed at this stage. It's a good point, and one that we think is reasonable to consider and evaluate as a possible follow on from this initial proposal. Kind regards, Patrick > On 25 Jun

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Anthony, Thanks for your suggestion of using a Stream.Builder instead of a Consumer. However, one of the goals for mapMulti is not to create an additional Stream. Also, I fear that using a builder, but throwing an exception on a call to build, is counter-intuitive and perhaps confusing to

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Patrick & Julia, this version starts to look good. I just don't understand why the new functional interfaces are not in java.util.function like the other ones ? (BTW, in the javadoc, the link to the summary overview point to the wrong one, to java.util.stream and not java.util.function).

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi, John: Thanks for your feedback. We've rearranged the ordering of the parameters of the BiConsumer to follow the convention you suggested, and hopefully improve readability going forward. Additional FIs (IntObjConsumer, etc.) have been added as sub-interfaces to the corresponding Stream

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Hi Sean, I think the changes look good including the proposed tweaks to the message suggested by Alan. Best Lance > On Jul 2, 2020, at 4:10 AM, Seán Coffey wrote: > > Thanks for the review Alan. I'm in contact with Max already about possible > follow up enhancements in this area. It would

Re: RFR 8245302: Upgrade LogRecord to support long thread ids and remove its usage of ThreadLocal

Hello, I have added comments @Serial based on csr feedback for read/writeObject methods. webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/ - rahul On 25/06/2020 10:22, Rahul Yadav wrote: Hello, Deprecated tag in LogRecord getter and setter for threadID was missing

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Thanks for the review Alan. I'm in contact with Max already about possible follow up enhancements in this area. It would be worked via a follow on JBS record. Regarding the error message, I'm fine with your suggestion. We can go with this then: "POSIX file permission attributes detected.

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

On 30/06/2020 14:51, Seán Coffey wrote: : During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). Yes, signing should be additive so the

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

Thanks for the review Max. All edits made bar the "Event.clearReportListener(Event.ReporterCategory.POSIXPERMS);" suggested edit. That's already in a finally block. latest webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v5/webrev/ I plan to push once I have a clean test run.