Current implementation of ZipFile.getEntryPos takes the encoded byte[] of the String we're looking up. Which means when looking up entries across multiple jar files, we allocate the byte[] over and over for each jar file searched.

By refactoring the ZipFile hash table to save a String-normalized hash value rather than a hash of the encoded value, we can avoid this allocation most of the time when the entry is not found in the jar/zip, while also getting the benefit of the caching of String.hashCode.

For jar files or any zip using UTF-8 encoding, calculating such hashes during open (initCEN) is easy to get as fast for ASCII entries. We could make the cost negligible for non-ASCII.

Experimental patch: http://cr.openjdk.java.net/~redestad/scratch/zipfile_string_hash.01

Instrumenting cost of ZipFile.getEntry shows a ~120ms improvement on Spring PetClinic, roughly 2.5-3% of total.