Re: (ch) InnocuousThread names

Looking at the code some more I wonder: *if defaultThreadFactoty should use a Thread group for the pool or at least for NIO? * If it can skip the security manager check and use InnocousThread in all cases (to avoid ThreadLocals - not sure if some encode cache is hurt by it?) * If

InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride)

Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/o

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13]

On Fri, 15 Oct 2021 15:09:23 GMT, Peter Levart wrote: >> It's not driven by performance data. It's part of Peter's contribution. >> I also prefer it without the packing. I propose to keep the parameter >> count as a separate field and examine it when there is footprint issue. > > The reas

Re: SourceVersion::feature

thank you! I replied on the PR. -michael On 16.10.21 01:19, Joseph D. Darcy wrote: PS See https://github.com/openjdk/jdk/pull/5973 -Joe On 10/14/2021 1:53 PM, Joseph D. Darcy wrote: On 10/14/2021 10:23 AM, Michael Bien wrote: is this the right mailing list for javax.lang.model.* discussions?

Re: RFR: 8266936: Add a finalization JFR event [v18]

> Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to > replace and mitigate Object.finalize() uses in the JDK libraries; please see > https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mit

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3]

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

AbstractProcessor overrides process(..) for no reason

Hi there, I've seen that javax.annotation.processing.AbstractProcessor overrides `Processor#process(..)` method without any changes to it [1]: - it still is abstract - signature is untouched - javadoc is untouched Is this done intentionally or this redundant override can be eliminated? [1]: https:

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6]

> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3]

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

Oh, sorry, I found that I misunderstood the closing time. I tried it in the wrong way, so I came to the wrong conclusion. Thank you for your reminder.

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

- Original Message - > From: "Glavo" > To: "Tagir F.Valeev" > Cc: "core-libs-dev" > Sent: Samedi 16 Octobre 2021 06:25:40 > Subject: Re: RFR: 8274412: Add a method to Stream API to consume and close > the stream without using try-with-resources > I don't think it is a perfect soluti