Has that system property ever documented in CSR? It's not in CSR for
JEP 280 [1]. Maybe other CSR?
Mandy
[1] https://bugs.openjdk.java.net/browse/CCC-8085796
On 5/23/20 6:18 AM, David Holmes wrote:
Hi Claes,
You are removing a property so this needs a CSR request.
Thanks,
David
On 22/0
On 23/05/2020 21:13, Rob Spoor wrote:
Hi,
I was working on upgrading a library of mine from Java 8 to 11, and I
noticed my unit tests started failing. Some investigation showed that in
Java 9, java.util.Properties was rewritten to no longer rely on the fact
that it extends Hashtable. One of t
Hi,
I was working on upgrading a library of mine from Java 8 to 11, and I
noticed my unit tests started failing. Some investigation showed that in
Java 9, java.util.Properties was rewritten to no longer rely on the fact
that it extends Hashtable. One of the changes was to use a private
static
Hi Christoph,
I agree this might not be called super often, but the refactoring is
straightforward and I think it clarifies the intent of the code, so
seems like a reasonable enhancement to make.
I've already volunteered to sponsor another patch of yours, so I might
as well pick this up too and
Hi Claes,
You are removing a property so this needs a CSR request.
Thanks,
David
On 22/05/2020 7:52 pm, Claes Redestad wrote:
Hi,
this patch removes the alternative, undocumented strategies from
StringConcatFactory.
The default strategy has been optimized and stabilized since inception
in J
On 15/05/2020 10:22, Severin Gehwolf wrote:
> Hi Andrew,
>
> Sigh, I only now realized that the bug number was missing the
> subject. Fixed now.
>
snip...
>>>
>>
>> Only issue with the patch itself is java.time.japanese.short.Eras is
>> missing the new Reiwa era. I guess this is because 11u
On 5/22/20 7:01 PM, Paul Sandoz wrote:
> We have made changes similar in spirit to the x64 ad file (reducing in size
> at least), so I think it reasonable request before integration to reduce the
> cognitive and maintenance burden.
So here's a question: can the changes to the AArch64 back end be
Hi,
I was looking through the code and found a relatively straight-forward
optimization in Executable.getAllGenericParameterTypes (attached below).
The idea is to simply move some code around to avoid unnecessary allocations
from getParameters() or array initializations when working with generic