JarFile.getVersionedEntry scalability with new release cadence

[Eirik Bjørsnøs]

I recently needed to re-implement multi-release lookup logic for a
ModuleReader capable of reading modules from unpacked (exploded) jar files
[1]

It occurred to me that JarFile.getVersionedEntry checks _every_ version
between 8 and the runtime version when looking up paths.

Since META-INF/versions will probably be sparsely populated, I'm wondering
if something could be done to avoid checking 20 different paths in OpenJDK
28.

Perhaps scanning META-INF/versions once when opening the file could work,
then only check existing versions in getVersionedEntry?

Maybe a premature optimization today, but with the new release cadence,
this problem is going to surface at some point in the future, right?

[1]
https://mail.openjdk.java.net/pipermail/jigsaw-dev/2020-April/014414.html

Eirik.