Handle the case of a Multi-Release Jar not actually containing Multi-Release Classes

[AterAnimAvis]

Seen a couple of people encounter this in mod dev (when adding dependencies):

SJH considers a Jar to be Multi-Release based on the Manifest

securejarhandler/src/main/java/cpw/mods/jarhandling/impl/Jar.java

Line 124 in 96a7b6a

this.isMultiRelease = Boolean.parseBoolean(getManifest().getMainAttributes().getValue("Multi-Release"));

If it is then it resolves a path to /META-INF/versions

securejarhandler/src/main/java/cpw/mods/jarhandling/impl/Jar.java

Line 126 in 96a7b6a

var vers = filesystem.getRoot().resolve("META-INF/versions");

And tries to walk it

securejarhandler/src/main/java/cpw/mods/jarhandling/impl/Jar.java

Line 127 in 96a7b6a

try (var walk = Files.walk(vers)){

This works for most Jars, however it does not consider the case where a Jar is erroneously marked as Multi-Release, with /META-INF/versions not existing.

If this is the case, Files.walk will throw a UnionFileSystem$NoSuchFileException which is then wrapped and rethrown as a UncheckedIOException

securejarhandler/src/main/java/cpw/mods/jarhandling/impl/Jar.java

Line 138 in 96a7b6a

throw new UncheckedIOException(ioe);

Attached Example Stacktrace, https://gist.github.com/AterAnimAvis/35ded98d52a78c2f257d59173c86366c

---

Current implementation of a fix is from a bit of spitballing in Discord

[heisluft]

Why not use Files.isDirectory() instead of relying on an exception being thrown?

[AterAnimAvis]

That's definitely an option (and probably the superior one), A few of us went through several options over on Discord fairly quickly, but I don't think that was raised.

It would require to change the code flow slightly around the setting of the final this.nameOverrides which I was personally hoping to avoid, but may be worth it.

[Technici4n]

This needs to be updated after the recent refactor of this code to JarContentsImpl.