Hi Claes, I'm OK with this. It would be help to add a simple comment to remind why we have to do this here, before there is better alternative in place for the startup. Thanks! Sherman On 12/5/17, 6:51 AM, Claes Redestad wrote:

Hi,

desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty startup regression on our smallest startup tests:

http://cr.openjdk.java.net/~redestad/8193064/open.00/

I think the implementation could be improved further by using static non-capturing functions rather than Jar-/ZipFileEntry::new (which, since they reference a non static class constructor, are implicitly capturing) and filed: https://bugs.openjdk.java.net/browse/JDK-8193066

Thanks!

/Claes

+1 nit: s/jarFileEntryFunction/newJarFileEntryFn/ Mandy On 12/5/17 6:51 AM, Claes Redestad wrote:

Hi,

desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty startup regression on our smallest startup tests:

http://cr.openjdk.java.net/~redestad/8193064/open.00/

I think the implementation could be improved further by using static non-capturing functions rather than Jar-/ZipFileEntry::new (which, since they reference a non static class constructor, are implicitly capturing) and filed: https://bugs.openjdk.java.net/browse/JDK-8193066

Thanks!

/Claes