RFR: JDK-8189611: JarFile versioned stream and real name support
Alan.Bateman at oracle.com
Mon Nov 20 14:42:03 UTC 2017
On 17/11/2017 16:53, Xueming Shen wrote:
> On 11/17/17, 3:35 AM, Alan Bateman wrote:
>> 1. getRealName is very welcome but I think it should be a no-arg
>> method on JarEntry, not JarFile. That would make it easier to use and
>> also avoids the temptation to call JarFile.getRealName with an entry
>> in a different JAR file.
> I was considering to put it into JarEntry. The only concern is that
> all mr jarfile related stuff
> are in JarFile, it's kinda easy/convenient to refer to the concept "if
> multi-release is..." in
> JarFile than JarEntry, especially considering mr jarfile normally
> should only be interested/
> used by limited group of developer, it might be better to simply put
> it near those mr related
> methods. But I don't have a strong opinion about it. I can move it
> into JarEntry, if it's desired.
The existing JarFile methods yield objects or streams of JarEntry. It
would be a bit inconsistent to introduce a method that returns an entry
name as a String. In the opposite corner, JarEntry defines getName and
it shouldn't be a surprise to have it define getRealName too.
The other awkward issue with getRealName(JarEntry) is that it has to
deal with the case that someone calls it with a JarEntry from a
different JarFile. And like getInputStream(JarEntry), it needs to be
concerned with a closed JarFile.
So I think on balance JarEntry::getRealName is better. It does mean that
the javadoc needs to reference the MR text in JarFile.
More information about the core-libs-dev