A DESCRIPTION OF THE FIX :
A collection of Locale fixes.

LocaleData.scanFile reads through the length of zip files on the classpath using ZipINputStream. I have replaced that with ZipFile that zips straight to the index. On my machine that improves the performance of the first call of Locale.getAvailableLocales by around *seven seconds*. I'm sure it could be done better still as we will have loaded classes through these zips. But this is the low hanging fruit.

LocaleServiceProvider.allAvailableLocales and  LocaleData.localeList are initialised with double-checked locking. I have replaced that with nested class initialisation.

The key used for the Locale cache is not unique for all possible arguments. In some cases it can fail to NPE, although I don't believe this is possible through the current usage within the package. The useful language constants also have bizarre duplication in their initialisation. I've replace the String key with a three element Arrays.asList.

Changed Locale.hashCode from lazy to eager initialisation. There is no great in deferring the initialisation. Doing it lazily complicates the hashCode method, requires another field and always recomputes for Locale("", "", "").

The LocaleISOData splits a String of country and ISO names. This means that the strings used are not interned (although the initialisation code is shorter). Strings used in actual locales are always interned. I've replaced it with more conventional initialisation to keep the strings interned as the class loads on demand rather than allocated twice later. The real overheads are in the locale property files.

Diffs against 1.6.0 ea b45.

(Diffs are too large to include here.  Refer to the attached
 file '504032-diffs.txt')