Build(deps): bump io.github.classgraph:classgraph from 4.8.191 to 4.8.192

[dependabot]

Bumps io.github.classgraph:classgraph from 4.8.191 to 4.8.192.

Release notes

Sourced from io.github.classgraph:classgraph's releases.

ClassGraph 4.8.192

ClassGraph 5.0.0 is coming shortly, and requires JDK 17 or newer. 4.8.192 is a bugfix release on the 4.x maintenance branch, and continues the file-by-file audit of the codebase that produced 4.8.190 and 4.8.191. As before, the bugs listed here were found by Claude through careful code analysis, and were fixed on the v5 branch and backported to v4.

Bug fixes: zipfile reading

• A zip entry name was decoded as UTF-8 whether or not the entry said it was UTF-8. The zip specification says a name is encoded in IBM Code Page 437 unless bit 11 of the entry's general purpose bit flag is set, and Windows Explorer and Info-ZIP are among the tools that follow it. So the name of an entry written by one of those tools came out as garbage as soon as it contained a byte outside ASCII, and the class or resource could not be found under the name it was stored with. The flag is now read before the name, and the name decoded as CP437 or UTF-8 accordingly. Malformed UTF-8 no longer throws either: an undecodable byte is replaced rather than the whole entry being lost, which is what java.util.zip does.

Bug fixes: resources

• Resource#read() returned a buffer covering the entire jarfile rather than the entry, when memory mapping was in use. The buffer's position was the entry's offset, so a sequential read returned the right bytes, but capacity() was the size of the whole jarfile, an absolute read such as get(0) read from the start of the jarfile, and clear() widened the buffer back out over the zip headers and every other entry. The mapping is now narrowed to the entry, so the buffer starts at position zero and cannot be widened again.

• A module resource's content was aliased rather than copied. The buffer belongs to the ModuleReader, which reclaims it when the resource is closed, so the content could change underneath a caller that kept the buffer.

Bug fixes: classpath order

• A classpath element named from more than one place got a single position, when it does not have one. The index of a classpath element within the Class-Path manifest entry (or lib directory) of the element that named it was stored on the child element rather than on the edge from the parent, and merged to the smallest index across every reference to that child. The same jarfile can be named by the Class-Path entries of two different jarfiles at a different position within each of them, so there is no one position it occupies.

  Two consequences, both of which decide which of two copies of a class masks the other: an element that was also listed on the top-level classpath sorted ahead of all of its parent's other entries, and an element named by two parents took the lower of its two indices under both, so it could tie with a sibling and fall back on whichever order the parallel scan tasks happened to finish in. Fixes #810.

Commits

• 1014e87 [maven-release-plugin] prepare release classgraph-4.8.192
• a10fafe Order child classpath elements by their position within each parent
• b804842 Return a buffer that covers only the requested resource
• c7d5192 Decode zip entry names as CP437 unless the entry says they are UTF-8
• 71fe4d9 [maven-release-plugin] prepare for next development iteration
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)