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.redes...@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
