RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect

Mandy Chung mandy.chung at oracle.com
Tue Mar 14 23:32:14 UTC 2017


I agree with the goal to reduce the number of qualified exports, which I always like to keep. 

Duplicating code like this isn’t ideal although it’s straight-forward.  This is a performance optimization. One solution is to keep using the Manifest API and check the attribute value equals to `true` and separate the performance issue and explore any other solution.  Perhaps parsing of Manifest could be optimized.

Mandy


> On Mar 14, 2017, at 11:42 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> Alan raised some concerns offline that we should try to reduce the
> number of qualified exports, not adding more, and that it might be
> better to accept some code duplication here. Thus I'm proposing this as
> an alternative:
> 
> http://cr.openjdk.java.net/~redestad/8176709/jdk.02/
> 
> Neither solution is exactly pretty, but this approach removes any
> performance risk of jdk.01 and by at least calling out that there's
> some duplication around should avoid us slipping back into a similar
> situation again.
> 
> Thanks!
> 
> /Claes
> 
> On 2017-03-14 16:04, Claes Redestad wrote:
>> Hi,
>> 
>> please review this change to adapt the JarFileSystem::isMultiReleaseJar
>> method to align with the evolved specification in JEP 238
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176709
>> Webrev: http://cr.openjdk.java.net/~redestad/8176709/jdk.01/
>> 
>> This unfortunately adds a qualified export from java.base to jdk.zipfs,
>> but since the jdk.internal.util.jar package was already exported to
>> three other modules I think it's a low cost option that is preferable
>> to other alternatives such as maintaining separate implementations.
>> 
>> Thanks!
>> 
>> /Claes



More information about the core-libs-dev mailing list