On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda wrote:
> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt
> terminal (see JDK-8270943), and to generally use a newer version of the
> library. This patch is basically a application of relevant parts of the diff
> between JLine 3
On Thu, 7 Oct 2021 16:48:06 GMT, Naoto Sato wrote:
>> StringBuffer is a legacy synchronized class. There are more modern
>> alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally
>> have
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
avoid link in private javadoc
-
Changes:
-
Classes compiled prior to the nestmate support will generate
`REF_invokeSpecial` if the implementation method is a private instance method.
Since a lambda proxy class is a hidden class, a nestmate of the host class, it
can invoke the private implementation method but it has to use
`REF_invoke
On Mon, 11 Oct 2021 18:52:07 GMT, Andrey Turbanov wrote:
>> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 275002: Remove unused AbstractStringBuilder.MAX_ARRA
On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich
wrote:
> The change completes the fix of
> [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has
> added normalisation in a constructor but not removed it from the get method.
Lgtm.
-
Marked as reviewed by p
I agree with the idea of a try() syntax, but i don't think we need more
interfaces.
Yes, John is right about the fact that the TWR Aucloseable does not work well
with checked exceptions,
but the issue is more that there is nothing that works well with checked
exceptions because Java has no way
On Mon, 11 Oct 2021 18:52:07 GMT, Andrey Turbanov wrote:
>> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 275002: Remove unused AbstractStringBuilder.MAX_ARRA
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
update javadoc of 'newCapacity' method to refer
ArraysSuppo
On Sun, 10 Oct 2021 22:13:29 GMT, Sergey Bylokhov wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>> update javadoc of 'newCapacity' method to refer
So the purpose of TWR is to hold an object with a “close-debt”
(debt of a future call to close) and pay it at the end of a block,
sort of like C++ RAII (but also sort of not).
But fluent syntaxes (which I like very much and hope to see
more of in the future!) don’t play well with blocks, so if a
f
On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan 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 of
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov
wrote:
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
JDK sources should not contain dead unused fields - thanks for fixing.
The change to use newLength in this file should have adjusted the javadoc of
newCapacity, perhaps simply
Hi Tagir,
Do you mind if we slow down on this and let the idea bake somewhat, captured in
this thread/issue/PR(draft).
I am always a little wary of compact-only or fluent-only methods, as I find
them harder to justify. In this case I think there might be something more with
regards to a patter
On Mon, 11 Oct 2021 13:42:35 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>> is
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the same
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil suggest
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
18 matches
Mail list logo
