RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect
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.
> On Mar 14, 2017, at 11:42 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 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:
> 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.
> On 2017-03-14 16:04, Claes Redestad wrote:
>> 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.
More information about the core-libs-dev