RFR: JDK-8189611: JarFile versioned stream and real name support

Alan Bateman 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 mailing list