Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

sample codes here https://github.com/openjdk/jdk/pull/5874 if anyone interested Xeno Amess 于2021年10月10日周日 上午4:00写道： > sigh. > > quite some good things I always want are at valhalla > , but I just don't think > they will come stable soon. > > hope me

Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

sigh. quite some good things I always want are at valhalla , but I just don't think they will come stable soon. hope me be wrong. Pavel Rappo 于2021年10月10日周日 上午1:54写道： > Empty? As in arrays of length zero? > > There ought to be a much better solutio

RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE

8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE - Commit messages: - [PATCH] Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE Changes: https://git.openjdk.java.net/jdk/pull/5878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5878&range=00 Issue: https:/

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

Created PR to remove AbstractStringBuilder.MAX_ARRAY_SIZE - https://github.com/openjdk/jdk/pull/5878 BTW, I found one more place where Integer.MAX_VALUE is used as maximum array length - java.util.concurrent.ScheduledThreadPoolExecutor.DelayedWorkQueue#grow I think this method could be reworked t

SourceVersion::feature

Hello, could javax.lang.model.SourceVersion receive a feature() method returning the version as an int, analog to java.lang.Runtime.Version? if (SourceVersion.latest().feature() >= 18) {} is simpler than comparing enums which may or may not exist dependent on the deployed java version and cl

Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

Empty? As in arrays of length zero? There ought to be a much better solution. I'm neither an expert nor (sadly) an active follower of the Valhalla project [1]. Perhaps something there or in Frozen Arrays [2] will address the runtime cost of creating zero-length arrays much more elegantly. [1]

Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

I suggest putting them in Arrays btw.

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

> On 9 Oct 2021, at 13:07, Pavel Rappo wrote: > > > > Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I > wonder how that happened. I found what happened: $ git log -S "MAX_ARRAY_SIZE" -- src/java.base/share/classes/java/lang/AbstractStringBuilder.java commit 036

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

This error has two causes. The first cause is that the VM cannot allocate arrays whose length exceeds Integer.MAX_VALUE - 8 (MAX_ARRAY_SIZE). The second cause is that Arrays.deepToString tries to pre-allocate 20 chars per string representation for each array element and maxes out at Integer.MAX_

Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2]

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about

Unexepcted OutOfMemoryError from Arrays.deepToString

Hello. I came across unexpected behaviour of Arrays.deepToString method. It throws OOM even on non-huge arrays. For example this code: int size = Integer.MAX_VALUE / 19; Integer[] integers = new Integer[size]; Arrays.fill(integers, 0); System.out.println(Arrays.deepToString(integers

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

- Original Message - > From: "Tagir F.Valeev" > To: "core-libs-dev" > Sent: Lundi 4 Octobre 2021 08:51:55 > Subject: RFR: 8274412: Add a method to Stream API to consume and close the > stream without using try-with-resources > Currently, when the stream holds a resource, it's necessa

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

On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with > try-with-resources. This undermines the compact and fluent style of stream > API calls. For example, if we want to get the `List` of files inside the > direct

Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux

On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from >> /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of >> /etc/localtime, because `readlink` can only read the value

Integrated: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo

On Thu, 8 Jul 2021 11:50:36 GMT, Wang Huang wrote: > Dear all, > Can you do me a favor to review this patch. This patch use `ldp` to > implement String.compareTo. > > * We add a JMH test case > * Here is the result of this test case > > Benchmark|(size)| M

Re: RFR: 8271598: CDS classlist file should support uber JARs

On Sat, 9 Oct 2021 00:15:43 GMT, Calvin Cheung wrote: > Currently, for archive classes for custom loaders, CDS supports the following > source locations in the classlist: I've added the core-libs label to this issue as this will require wider discussion, detailed review of the classes that are