On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version o
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).
>
Consensus seems to be we leave the existing manual test alone. I've updated
the PR to leave the existing test as-
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version o
I think it is fine to move the validation immediately following findEND()
though I am not sure there is a big win overall.
I also would prefer to see the test based off of an actual ZIP(or at least have
the current/modified version of the test). I would prefer to avoid having
another place wh
On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman
wrote:
> The intention of the test was exercise a multi-GB CEN. So I think it
>
would be great if it could be re-written as an automatic test but I
> think it should be a real ZIP file, make use of sparse files might help.
>
Alan,
Yes, this change do
On 26/01/2023 18:57, Eirik Bjørsnøs wrote:
Hi,
This PR updates the test TestTooManyEntries to not create gigabytes of
ZIP files, allowing the test to run fast and non-manual:
https://github.com/openjdk/jdk/pull/12231
May I please get some help with filing a JBS for this PR?
The intention of th
