-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit #12563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… copies which are now obsolete.
👋 Welcome back eirbjo! A progress list of the required criteria for merging this PR into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Eirik,
Thank you for your suggested changes to this test.
I think if we are going to re-work this test, we should go further including improving the comments for future maintainers
I made a quick pass and some initial thoughts are below
Best
Lance
private byte[] good; | ||
// Copy of the template for modification in tests | ||
private byte[] bad; | ||
// Some well-known locations in the golden ZIP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be a good opportunity to provide better naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went for "template" and "copy" here.
|
||
@BeforeTest | ||
public void setup() throws IOException { | ||
// Make a ZIP with a single entry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change either this method name or the other setup()
method.
I would also add a Files.delete(zip) here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed the @BeforeMethod
one to makeCopy
// Read the contents of the file | ||
good = Files.readAllBytes(zip); | ||
Files.delete(zip); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a cleanup
method in addition to deleting earlier on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one I did not fully understand. In any case, there is really no need to write the template ZIP to disk, so I opted for a ByteArrayOutputStream instead. I added a cleanup method to delete the ZIP file produced by each test.
good = Files.readAllBytes(zip); | ||
Files.delete(zip); | ||
|
||
// Set up some well-known offsets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please expand the comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
* Make a copy safe to modify by each test | ||
*/ | ||
@BeforeMethod | ||
public void setUp() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, please rename this method or the other
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, renamed to makeCopy
} | ||
|
||
@Test | ||
public void corruptedENDSIZ() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment to this and the other tests describing the purpose of the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have given each @Test
method a more meaningful name and added comments explaining the constraint or error condition being tested.
assertTrue(ex.getMessage().matches(msgPattern), | ||
"Unexpected ZipException message: " + ex.getMessage()); | ||
|
||
} catch (IOException e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another option is to throw the IOException and add IOException to the test method signature as we are going to fail anyways for the IOException
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to propagate the IOException
} | ||
|
||
static int uniquifier = 432; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure how many people would know what a uniquifier
is though it is an interesting phrase which I know from SQL Server. Perhaps consider renaming this variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need unique file names for this test. Opted for a single ZIP Path instead and removed this variable.
Hopefully this test is now easier to understand for someone who is not intimately familiar with the ZIP format. I am hearing a voice in the back of my head (Martin?) saying "this level of documentation is excessive" though. As always a trade off I guess. |
/issue 8304014 |
@eirbjo The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated. |
Webrevs
|
…r. Collapse the checkZipException and checkZipExceptionInGetInputStream into one method by always consuming the InputStream. Add a block comment for the assertZipException method.
High level comment: these days we usually try to use junit 5 / jupiter instead of TestNG. |
I think my choice of testNG here might have been influenced by other ZIP area tests using testNG. I guess a rewrite to junit should be pretty straightforward. @LanceAndersen Do you have any opinion on junit/testNG for tests like this? |
Here's a junit version for consideration: |
We have had some discussion about using junit vs testNG but we have not mandated it so I am OK with either but certainly if you would like to move to junit as it should be fairly straight forward for this test, I think that would be nice |
Let's go with reviewing this version, Thank you for the update Eirik |
Good, I pushed the junit version to the PR. Also updated the JBS and PR titles. Big thanks to @dfuch for suggesting, your lower-level comments are also welcome! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Eirik, thanks for following up on my suggestion :-)
import org.junit.After; | ||
import org.junit.Before; | ||
import org.junit.BeforeClass; | ||
import org.junit.Test; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you should be using corresponding annotations from org.junit.jupiter.api
instead.
From https://junit.org/junit5/docs/current/user-guide/index.html#migrating-from-junit4
@Before
and@After
no longer exist; use@BeforeEach
and@AfterEach
instead.
@BeforeClass
and@AfterClass
no longer exist; use@BeforeAll
and@AfterAll
instead.
Similarly the @Test
annotation should be imported from org.junit.jupiter.api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noob question: Do you know where I find the jars for setting up junit5 in my IDE? jtreg's junit-platform-console-standalone-1.9.2
does not seem to include these annotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems my dev environment has jtreg
< 7. Maybe that's a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems junit 5 support is a recent effort?
https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scratch that. It seems my IDE was just not being very cooperative in suggesting or finding JUnit 5 API. When I wrote the imports myself it seems to have improved its behaviour.
Do you think it looks better now, @dfuch ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - this a recent effort. I believe you will need at least jtreg 7, and JUnit 5.8.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is worth noting that I did a new local build of jtreg and that may have updated the junit API jar.
I would find that weird because the file name or version of the JAR file was not updated jtreg/build/deps/junit/junit-platform-console-standalone-1.9.2.jar
. But maybe the content of the file changed?
Following an offline discussion with Lance, I added the following improvements:
|
@Martin-Buchholz this PR suggests we can improve the Would be interested in hearing if you agree this is an improvement? If not, why? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your recent updates Eirik, I think this looks good.
A few minor comment suggestions
I will get a Mach 5 run done as a sanity check
/* | ||
* Byte array holding a valid template ZIP. | ||
* | ||
* This 'good' ZIP file has the following structure: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change this -> the
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
return data[offset]&0xff; | ||
/* | ||
* Validate that a ZipException is thrown when the 'End of Central Directory' | ||
* (END) header has a CEN offset incoherent with the position calculated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure incoherent is the best term.
perhaps something along the lines:
header contains an invalid CEN Directory starting offset.....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember my struggles trying to write this one in the first place. The code says:
long cenpos = end.endpos - end.cenlen; // position of CEN table
// Get position of first local file (LOC) header, taking into
// account that there may be a stub prefixed to the zip file.
locpos = cenpos - end.cenoff;
if (locpos < 0) {
zerror("invalid END header (bad central directory offset)");
}
so I ended up trying to express this equation in words, which is maybe not so successful. I don't see incoherent as the main problem, if it was we could just use inconsistent.
Do you have a better concrete suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep it simple and indicate that the offset of start of central directory field within the End Header was given an invalid value
return u8(data,offset) + (u8(data,offset+1)<<8); | ||
/* | ||
* Validate that a ZipException is thrown when a A CEN header has an unexpected signature | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change "a A" to "a"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support rewriting tests like this into junit 5.
I wrote many jdk tests (like this) before a standard high quality test framework like junit 5 was available.
Zip file implementations are 90% corner cases, so expanding testing and improving testability of jdk classes would be valuable. For example, it would be nice to explicitly request use of ZIP64 extensions even when they are not needed, to avoid having to create multi-gigabyte test files.
static final int LOCEXT = ZipFile.LOCEXT; | ||
/* | ||
* Validate that a ZipException is thrown if the last CEN header is | ||
* not immediatly followed by the start of the 'End of central directory' record |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: immediatly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed.
} | ||
|
||
/* | ||
* Validate that a ZipException is thrown when a LOC header has an unexpected signature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave off "Validate that"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, updated all test comments to strip this shared prefix.
Glad to hear! I would be a bit sad to hear you were against this.
And thank you for that!
Indeed. I would also just love to be able to transform existing ZIP files into Zip64 format, regardless of their current format. And along the way transform any ZIP record or field in a type-safe manner. Stay tuned for suggestions in this area.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last Mach5 runs continue to be clean so you are good to integrate and then I can sponsor Monday
Thank you for your efforts on this clean up Eirik.
@eirbjo This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 64 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@LanceAndersen, @dfuch, @Martin-Buchholz) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Updated the /integrate |
/sponsor |
Going to push as commit 85e3974.
Your commit was automatically rebased without conflicts. |
@LanceAndersen @eirbjo Pushed as commit 85e3974. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
CorruptedZipFiles could benefit from some spring cleaning and a conversion to junit:
@Test
methods, given more meaningful names and a Javadoc comment explaining the constraint being verified@Before
method, slightly modernized and rewritten to take advantage ofassertEquals
checkZipExceptionImpl
is updated to take advantage ofassertThrows
ZipFile
can be deleted since JDK-6225935 has long been fixedProgress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/12563/head:pull/12563
$ git checkout pull/12563
Update a local copy of the PR:
$ git checkout pull/12563
$ git pull https://git.openjdk.org/jdk.git pull/12563/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12563
View PR using the GUI difftool:
$ git pr show -t 12563
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12563.diff