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
