Which "default Locale" is which?

Question

With UNIX locales, the breakdown of which means what is relatively well documented.

• LC_COLLATE (string collation)
• LC_CTYPE (character conversion)
• LC_MESSAGES (messages shown in UI)
• LC_MONETARY (formatting of monetary values)
• LC_NUMERIC (formatting of non-monetary numeric values)
• LC_TIME (formatting of date and time values)
• LANG (fallback if any of the above are not set)

Java has a different categorisation which doesn't quite match the real world (as usual):

• Locale.getDefault()
• Locale.getDefault(Locale.Category.DISPLAY)
• Locale.getDefault(Locale.Category.FORMAT)

If you read the documentation on these, Locale.getDefault(Locale.Category.DISPLAY) appears to correspond to LC_MESSAGES while Locale.getDefault(Locale.Category.FORMAT) appears to correspond to some combination of LC_MONETARY+LC_NUMERIC+LC_TIME.

There are problems, though.

If you read the JDK source, you start to find many worrying things. For instance, ResourceBundle.getBundle(String) - which is entirely about string messages - uses Locale.getDefault(), not Locale.getDefault(Locale.Category.DISPLAY).

So I guess what I want to know is:

Which of these methods is supposed to be used for which purpose?

Related, but I made a little test program to see which Java locales corresponded to which UNIX locales and got even more surprising results.

import java.util.Locale;

public class Test {
    public static void main(String[] args) {
        System.out.println("  Unqualified:  " + Locale.getDefault());
        System.out.println("  Display:      " + Locale.getDefault(Locale.Category.DISPLAY));
        System.out.println("  Format:       " + Locale.getDefault(Locale.Category.FORMAT));
    }
}

Locales according to my shell:

$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

Output of the program:

$ java Test
  Unqualified:  en_AU
  Display:      en_AU
  Format:       en_AU

So it turns out Java doesn't even get it from the UNIX locale. It must be using some other back door to get the settings without using those.

Answer 1

It's hard to understand what you are asking here. Instead, you make a statement that reveals that you're not necessary a Java programmer. It's OK, it does not matter really.

Few things to clarify:

• The Locale class is in JDK since Java 1.1
• Things like Locale.Builder, Locale.Category and many others are here from Java 7 (JDK 1.7)
• Locale-aware classes and methods like DateFormat, NumberFormat, Collator, ResourceBundle, String.toLowerCase(Locale), String.toUpperCase(Locale) and many, many more are here for quite a long time each (long before JDK 1.7)
• Prior to Java 7/JDK 1.7 there was only one method of acquiring current OS Locale - call Locale.getDefault() (that is without parameters)

In other words, prior to Java 7, Java's Locale Model was as simple as one system property composed of a language, a country and an optional locale variant. That has changed with Java 7 (end was further extended with Java 8...) and now you have two system properties, one for formatting and one for displaying user interface messages.
The problem is, there is substantial amount of legacy code written in Java and this could shouldn't break when you upgrade the platform. And that is exactly why you still have parameterless Locale.getDefault() around. Moreover (you may test it yourself), Locale.getDefault() is basically interchangeable with Locale.getDefault(Locale.Category.DISPLAY).

Now, I said formatting and user interface messages. Basically, formatting is not only formatting, but things like character case conversion (LC_CTYPE), collation (LC_COLLATE) as well. Sort of anything but user interface messages. Sort of, because default character encoding (which depends on an OS, BTW) is not part of Locale. Instead you need to call Charset.defaultCharset().
And the fallback rules (built in Java, not read from OS) could be worked out with ResourceBundle.Control class. And as we know, it is rather related to UI category...

The reason why Java Locale Model is different from POSIX (not UNIX, it's more universal), is the simple fact that there are quite a few platforms out there. And these platforms doesn't necessary use POSIX... I mean not only Operating Systems, but things like web... Java is striving to be universal and versatile. As the result Java's Locale Model is convoluted, tough luck.

I have to add that nowadays, it's not only the language and the country, but there are also things like preferred script, calendar system, numbering system, specific collation settings and possibly more. It even works sometimes.