Why is NumberFormat.cachedLocaleData still a Hashtable?

Question

Looking at JDK 6, NumberFormat.getInstance(Locale) is a bottleneck at high concurrency, because it hits a synchronized block calling cacheLocaleData.get(locale). The latter is a Hashtable - shouldn't it be a ConcurrentMap by now?
Not sure what LocaleServiceProviderPool is but it appears to not have providers so the executions does hit cacheLocalData.get() on every invocation. The problem is many web frameworks rely on MessageFormat or NumberFormat.getInstance() to convert presentation data String<>Int and so this method may get called 100s of times per page render (imagine rendering a table of formatted numbers).
Is the workaround to 'new' DecimalFormat directly and put it on a ThreadLocal (to avoid calling NumberFormat.getInstance())?
private static final Hashtable cachedLocaleData = new Hashtable(3);
    private static NumberFormat getInstance(Locale desiredLocale,
                                           int choice) {
        // Check whether a provider can provide an implementation that's closer
        // to the requested locale than what the Java runtime itself can provide.
        LocaleServiceProviderPool pool =
            LocaleServiceProviderPool.getPool(NumberFormatProvider.class);
        if (pool.hasProviders()) {
            NumberFormat providersInstance = pool.getLocalizedObject(
                                    NumberFormatGetter.INSTANCE,
                                    desiredLocale,
                                    choice);
            if (providersInstance != null) {
                return providersInstance;
        /* try the cache first */
        String[] numberPatterns = (String[])cachedLocaleData.get(desiredLocale);
        if (numberPatterns == null) { /* cache miss */
            ResourceBundle resource = LocaleData.getNumberFormatData(desiredLocale);
            numberPatterns = resource.getStringArray("NumberPatterns");
            /* update cache */
            cachedLocaleData.put(desiredLocale, numberPatterns);
        }

Answer 1

nikita_bludevil wrote:
Is the workaround to 'new' DecimalFormat directly and put it on a ThreadLocal (to avoid calling NumberFormat.getInstance())?I would use a ThreadLocal