On Mon, 11 Dec 2023 17:22:14 GMT, Eirik Bjorsnos <d...@openjdk.org> wrote:
> > One quick comment, if we are updating this test, we should look to get rid > > of input.zip > > I started going down that road, but felt uneasy about the amount of unrelated > changes in a single PR. I'd like to make efficient use of reviewer time, so > my preference was to focus on the JUnit conversion, without too many other > changes. > > If you prefer that we get rid of input.zip and also convert the affected > tests to JUnit in the same PR, then I'm happy to switch strategy. > > Note that `StreamZipEntriesTest` also uses `input.jar`, this is also read by > `Available`, `CopyJar`, `GetDirEntry`, `ReleaseInflater`. Should we get rid > of `input.jar` as well, or perhaps defer that to a follow-up? input.zip and input.jar are pretty trivial: > jar tvf test/jdk/java/util/zip/ZipFile/input.zip > 506 Fri May 28 16:32:31 EDT 1999 ReadZip.java > jar tvf test/jdk/java/util/zip/ZipFile/input.jar > 0 Tue Mar 23 13:09:08 EST 1999 META-INF/ > 86 Tue Mar 23 13:09:08 EST 1999 META-INF/MANIFEST.MF > 728 Tue Mar 23 13:08:30 EST 1999 ReleaseInflater.java So you could have the tests create the zip files on the fly or store the contents in an array within the tests. If the tests create the zip file/jar on the fly, then we just need to make sure that we create it in the same fashion as the test needs. I just think that we should take this opportunity as part of re-writing the tests to remove the need for the binary files in the workspace. I don't have a preference whether we deal with input.jar separately, but these tests are not that complex so I do not see a risk if they are all converted at once, or done piece meal ------------- PR Comment: https://git.openjdk.org/jdk/pull/17038#issuecomment-1850559536
