java - Which "default Locale" is which? -

with unix locales, breakdown of means relatively 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 , time values)
• lang (fallback if of above not set)

java has different categorisation doesn't quite match real world (as usual):

• locale.getdefault()
• locale.getdefault(locale.category.display)
• locale.getdefault(locale.category.format)

if read documentation on these, locale.getdefault(locale.category.display) appears correspond lc_messages while locale.getdefault(locale.category.format) appears correspond combination of lc_monetary+lc_numeric+lc_time.

there problems, though.

if read jdk source, start find many worrying things. instance, resourcebundle.getbundle(string) - entirely string messages - uses locale.getdefault(), not locale.getdefault(locale.category.display).

so guess want know is:

which of these methods supposed used purpose?

related, made little test program see java locales corresponded unix locales , got 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 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 program:

$ java test   unqualified:  en_au   display:      en_au   format:       en_au 

so turns out java doesn't unix locale. must using other door settings without using those.

it's hard understand asking here. instead, make statement reveals you're not necessary java programmer. it's ok, not matter really.

few things clarify:

• the locale class in jdk since java 1.1
• things locale.builder, locale.category , many others here java 7 (jdk 1.7)
• locale-aware classes , methods dateformat, numberformat, collator, resourcebundle, string.tolowercase(locale), string.touppercase(locale) , many, many more here quite long time each (long before jdk 1.7)
• prior java 7/jdk 1.7 there 1 method of acquiring current os locale - call locale.getdefault() (that without parameters)

in other words, prior java 7, java's locale model simple 1 system property composed of language, country , optional locale variant. has changed java 7 (end further extended java 8...) , have 2 system properties, 1 formatting , 1 displaying user interface messages.
problem is, there substantial amount of legacy code written in java , shouldn't break when upgrade platform. , why still have parameterless locale.getdefault() around. (you may test yourself), locale.getdefault() interchangeable locale.getdefault(locale.category.display).

now, said formatting , user interface messages. basically, formatting not formatting, things character case conversion (lc_ctype), collation (lc_collate) well. sort of user interface messages. sort of, because default character encoding (which depends on os, btw) not part of locale. instead need call charset.defaultcharset().
, fallback rules (built in java, not read os) worked out resourcebundle.control class. , know, rather related ui category...

the reason why java locale model different posix (not unix, it's more universal), simple fact there quite few platforms out there. , these platforms doesn't necessary use posix... mean not operating systems, things web... java striving universal , versatile. result java's locale model convoluted, tough luck.

i have add nowadays, it's not language , country, there things preferred script, calendar system, numbering system, specific collation settings , possibly more. works sometimes.