RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v3]

[Alan Bateman]

On 03/07/2021 17:19, Jaikiran Pai wrote:
> :
>
>
> There are still some decisions to be made:
>
> 1. Should we introduce this new property or should we enhance the existing "useTempFile" property to allow a size to be passed?
It's an implementation tuning knob and highly unlikely to be in the 
environment specified to newFileSystem. So I think the simplest is to 
just leave it out, it can always be added at a later time if there is a 
new real need. The default that you've chosen (10MB) looks a reasonable 
value to start with.

BTW: The documented properties that can specified in the environment are 
in jdk.zipfs's module description. The useTempFile property is not 
listed here as it was never a documented/supported property that dates 
back to early iterations of the zip file system when it was a demo.

As the PR has now expanded to do JDK-8011146 (and it doesn't matter if 
you use that JBS issue or continue with JDK-8190753) then I think the 
priority should be to be confident with the security.

> 4. I've never previously created a manual test case. The `LargeCompressedEntrySizeTest` in this PR is expected to be a manual test case (given how long it might take to run on various different systems). The only difference between this test case and other jtreg automated tests is the absence of a `@test` on this one. Is this how manual tests are written or is there some other way?
>
We avoid manual tests as there is no guarantee that they will be run. So 
maybe we'll need to explore the scenario a bit further to see if there 
is some way to come up with an automated test. The jtreg foo for manual 
tests is `@run main/manual LargeCompressedEntrySizeTest`. You'll see a 
few examples in the test suite but I don't know if they are ever run.

-Alan