Re: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel Processing

2024-10-17 Thread xxDark
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote: > [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing > Overhead & Inefficient Parallel Processing This seems like an AI-generated change... Also, turning a stream into a parallel one is a recipe for disaster. Consider

Re: RFR: 8233451: (fs) Files.newInputStream() cannot be used with character special files [v2]

2024-10-16 Thread xxDark
On Tue, 15 Oct 2024 22:37:26 GMT, Brian Burkhalter wrote: >> Add `isOther` and `available` methods to `FileChannelImpl` and the >> interfaces to native code and use these in `ChannelInputStream` to work >> around cases where a wrapped `FileChannelImpl` is not really seekable. > > Brian Burkhalt

Re: RFR: 8334714: Class-File API leaves preview [v2]

2024-08-23 Thread xxDark
On Sat, 24 Aug 2024 04:56:34 GMT, Chen Liang wrote: > > Indeed, it would be a good RFE to allow users to override default attribute > mappers to parse attributes; this would be extremely useful if users wish to > support previous previews that only differed in the attribute formats. > I don't

Re: RFR: 8334714: Class-File API leaves preview [v2]

2024-08-23 Thread xxDark
On Sat, 24 Aug 2024 03:45:03 GMT, Chen Liang wrote: > While your account of oak format seems interesting (from a search, it seems > to use u1 for max stacks/locals, u2 for Code size), it is neither recognized > by hotspot (the reference implementation for JVM): > > https://github.com/openjdk/j

Re: RFR: 8334714: Class-File API leaves preview [v2]

2024-08-23 Thread xxDark
On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes >> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please rev

Re: RFR: 8329760: Add indexOf(Predicate filter) to java.util.List interface [v11]

2024-04-23 Thread xxDark
On Fri, 19 Apr 2024 22:20:48 GMT, Evemose wrote: > > I noticed that most (if not all) methods don't ensure non-nullability of > > `filter` so NPE would only be thrown if the list is not empty. > > Yeah, thats true. not sure if it has to throw NPE even if list is emply Yes, it does. If it shoul

Re: RFR: 8329760: Add indexOf(Predicate filter) to java.util.List interface [v11]

2024-04-19 Thread xxDark
On Fri, 19 Apr 2024 15:49:11 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more f

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface

2024-04-18 Thread xxDark
On Tue, 9 Apr 2024 21:48:23 GMT, Evemose wrote: > One possible workaround is to temporally (for an intermidiate period) or > permanently delegate null value handing to indexOf(Object), which seems odd > for me to me tbh, although it preserves source compatibility. This does not solve the probl

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface

2024-04-18 Thread xxDark
On Fri, 5 Apr 2024 00:00:58 GMT, Evemose wrote: > **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-24 Thread xxDark
On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon wrote: > > I'm still puzzled by the need to do this as any non-delegating classloader > > would have allowed this even if JVMCI were loaded by the bootloader. > > As far as I understand, even a non-delegating classloader cannot redefine a > class lo

Re: RFR: 8323832: Load JVMCI with the platform class loader

2024-01-23 Thread xxDark
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote: > This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform > class loader instead of the boot class loader. This allows Native Image to > load a version of JVMCI different than the version on top of which Native > Image is