Bug ID: JDK-4071298 java.lang.Locale.getDefault() is a public static

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other	Other
1.1.6 1.1.6Fixed	1.2.0Fixed


Name: sv38254			Date: 08/12/97


java.lang.Locale.getDefault() is a public static
synchronzied method.  This means it is a bottle neck for the
WHOLE VM.  This is totally unacceptable for high-end,
high-performance server-side Java processes.  This is totally unnecessary...

e.g. the source code is currently

    public static synchronized Locale getDefault() {
        if (defaultLocale == null) {
	    String language = System.getProperty("user.language", "EN");
	    String region = System.getProperty("user.region", "");

	    defaultLocale = new Locale(language, region);
	}
        return defaultLocale;
    }

You could recode this so the whole method is not synchronized and when you determine that the defaultLocale
is null then peform an internal synchronization

This should make things much better.

You really have to examine all the APIs so they are not
so Applet centric.  This sort of coding style is not a problem when you're running a couple of applets - but if
you are running hundreds of simulatenous threads (which we do on the server-side) then this sort of bottleneck is a nightmare.
======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2beta3 generic FIXED IN: 1.1.6 1.2beta3 INTEGRATED IN: 1.1.6 1.2beta3 VERIFIED IN: 1.1.6

14-06-2004

WORK AROUND Name: sv38254 Date: 08/12/97 ======================================================================

11-06-2004

EVALUATION The customer is largely correct. In fact, you don't even need the internal synchronization, as it's not critical that all callers return the same Locale object. Thus, it would be perfectly acceptable to just remove the 'synchronized' modifier, outright! (Note that this depends on the atomicity of storing the Object reference, which the language does guarantee.) joshua.bloch@Eng 1997-08-13

13-08-1997

Duplicate :	JDK-4101184 - java.util.Locale.getDefault is synchronized
Relates :	JDK-7117936 - java.util.Locale getDefault() initialization is broken