On 9 Mar 2016, at 13:03, Claes Redestad <claes.redes...@oracle.com> wrote:
> On 2016-03-09 13:17, Peter Levart wrote: >>> >>> When digging through old history to try to find out why >>> java.util.jar.Attributes >>> was ever using ASCIICaseInsensitiveComparator, it was not clear that >>> performance was the motivation. >> >> I guess looking-up a manifest attribute is not a performance critical >> operation, you are right. > > Could this be an old startup optimization, since first call to > String.toLowerCase/toUpperCase will initialize and pull in java.util.Locale > and friends? If so it's probably not effective any more. > > Coincidentally - due to a recent regression - we're currently spending quite > a bit of time parsing manifests of all jar files on the classpath, making > ASCIICaseInsensitiveComparator show up prominently in some startup profiles. Not any more ( it is no longer with us )!! Interesting… let me know if you issues once this change makes its way into a promoted build, or during your performance investigations. BTW. I am not against doing something “smarter” for Attributes.hashCode. I just didn’t think it was relevant, or performance sensitive, any more. -Chris
