This problem happens in b54 JCG pit build and will happen in promotion build (possibly from b55) when 6336885 is fix delivered.
If the Locale is constructed with both language and country/region code, the CLDR adapter often can not be used, even it's the first in java.locale.providers. For example, if the Locale is new Locale("zh", "CN"), CLDR adapter will not be loaded even it's the first in the list of java.locales.providers. If we use new Locale("zh"), CLDR adapter will be loaded.
In Java, if we do not specify the Locale when calling methods like DateFormat.getTimeInstance(), the default locale is used. In this case, CLDR adapter sometimes can not be loaded, but some other times, CLDR adapter will be loaded. For exmaple, if default locale is en_GB, en_CA and some others, when CLDR adapter is in the first of provider list, it will be loaded, while when default locale is en_US, CLDR adapter will not be loaded even it's the first of provider list. This inconsistency will make the user confused. On some underlying OS, for example, windows en_GB, the CLDR adapter is used, while on some other OS, for example, windows en_US, the JRE adapter is loade, though the adapter options are the same.
I set the priority as 4, because there is the option NOT to add JRE locale data as fall back data. When JRE adapter is not the fallback, above problem will disappear.
Sorry that so far I can not find the option not to add JRE as the fallback.