On Tue, 7 Apr 2026 16:29:33 GMT, Marcono1234 <[email protected]> wrote:
>> Jaikiran Pai has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commits since the last revision:
>>
>> - review comments
>> - fix typo in code comment
>> - merge latest from master branch
>> - 8378291: Test vector in
>> test/jdk/java/util/jar/JarEntry/GetMethodsReturnClones.java is effectively
>> unsigned
>
> test/jdk/java/util/jar/JarEntry/GetMethodsReturnClones.java line 76:
>
>> 74: static void beforeAll() throws Exception {
>> 75: Path unsigned = createJar();
>> 76: Path signed = signJar(unsigned);
>
> Should these files be deleted again (maybe in a `@AfterAll`?) after the test
> finished?
jtreg uses a "scratch" directory for each test. That scratch directory is also
the "current working directory" of the process that runs the test. So when
files are created (like in this test), unless explicitly created outside of
these directories, they get created relative to the scratch directory. jtreg
manages the lifetime of the scratch directory and if a test fails, then it
retains the file in those directories (it is configurable). The advantage of
not deleting these files explicitly in the test is that if a test fails, then
these files are handy during the investigation and if the test succeeds then
jtreg itself cleans them up (it's configurable through the "-retain" option).
So unless there's a specific need to delete these files, it's OK to leave them
around. We don't enforce it though, and some tests delete them explicitly and
some leave them around.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30602#discussion_r3050647976
