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