Stephen,
I think the use-case can be pretty well defined.
There should be an enumeration/iterator/stream available that provides the
contents of a jar file as it would be seen/interpreted by the JVMs
classloader.So if the classloader is doing any processing to handle
versioned classes/resourc
Thanks for the clarification – I overstated the “any JarEntry”.
I didn’t look at VersionedStream so I now understand the limitations you
mention.
In my case, it’s necessary to look at all files in the jar file to do the
elimination of unneeded ordinary/inner classes so JarInputStream
getNex
Stephen,
It is not the case that the getName() always returns the path starting with
"META-INF/versions/". Specifically, if the entry is obtained from
getJarEntry() API (and not from the enumerator), then the name is that of
the unversioned file, but the metadata and contents obtained using the
ja
A versioned file name, JarEntry.getName(), starts with "META-INF/versions/".
The version is the following string up to the next "/".
The version can be parsed with Runtime.Version.parse().
If not a versioned class file name, then use Jarfile.baseVersion().
That should be sufficient to get the versi
Paul,
yeh... I guess I concede it's not JarFiles job... as much as that would
make things easier for containers to reach agreement:(
However, can we at least look at having a new default method on JarEntry to
query the version. Without that, containers don't have the information
available to perf
I agree with Alan here, we should not be pushing a semantic understanding of
inner classes into JarFile.
I do sympathise with the case of annotation class scanning, which has always
tunnelled through the class loader view to directly get at class file bytes
possibly dealing with various URI sc
