On Fri, 27 Oct 2023 12:10:07 GMT, Raffaello Giulietti
wrote:
>> By correctly sizing an intermediate `byte[]` and making use of the internal
>> `newStringNoRepl()` method, one allocation per conversion can be avoided
>> when the runtime uses compact strings.
>
> Raffaello Giulietti has updated
On Sat, 17 Feb 2024 01:01:49 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> assertNotEqualsByteArray
>
> test/lib/jdk/test/lib/Asserts.java line 285:
>
>> 283: * @param lhs The left hand sid
> Many crypto service classes require a `SecureRandom` object at
> initialization. This test goes through each of them and calculates (generate,
> encrypt, sign,...) twice with the same `SecureRandom` object and ensures the
> output is the same.
Weijun Wang has updated the pull request incremen
Please review this test-only cleanup PR in preparation for deprecating
`Deflater.getTotalOut()` in JDK-8326096.
This PR replaces various calls
in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to
`Deflater.getTotalOut()` when formatting some debugging output lines.
Additionally, various
Please review this cleanup PR in preparation for deprecating
`Deflater.getTotalIn()` in JDK-8326096.
This PR replaces `GZIPOutputStream.writeTrailer`'s call to
`Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` followed by an
explicit conversion to "modulo 2^32" (a cast to int) a
On Sat, Feb 17, 2024 at 9:09 AM Alan Bateman
wrote:
> So I think there is good case for deprecating the old methods.
>
Thanks Alan, I'll take this task on and have filed the following task to
track it: https://bugs.openjdk.org/browse/JDK-8326096
Cheers,
Eirik.
On 16/02/2024 19:20, Eirik Bjørsnøs wrote:
Hi,
Initially, the Deflater and Inflater classes in java.util.zip only
supported up to 2GB of inflated or deflated data, the reason being
that their getTotalIn and getTotalOut methods returns an int.
Around 2004, this limitation was remedied by intr
