Why Java locales are not constants?
Asked Answered
T

5

9

Java supports the Locales shown in this link.

But I can't figure out why only some countries such as France, Canada, China and United States and some languages such as Italian, Japanese and German have constants for their locales.

Everytime a need a locale, I consult the table of supported locales and do the following, using Strings:

Locale locale = new Locale("pt", "BR");

Why only some locales as constants?
Is there a Java library which provide constants for locales?

Tenaille answered 7/11, 2014 at 10:42 Comment(3)
You can always make your own constant ;)Product
When you say constant, what do you mean? The Locale attributes in java.util.Locale are static, but not constant. What is the constant bit that you are referring to?Overdye
Constant means (public/private) static final TYPE NAME = VALUE;. Locale.ITALY, for example, is documented as "Useful constant for country".Tenaille
H
8

Why only some locales as constants?

The javadoc for Locale says this about the constants:

"The Locale class provides a number of convenient constants that you can use to create Locale objects for commonly used locales."

The obvious implication is that Locale constants have not been defined for other countries and languages because the locales were thought at the time to be "less commonly used" in Java programs. Or at least, not common enough to warrant adding the corresponding constants. (I have no idea if this decision was made based on objective evidence or not.)

Be aware that there would be performance overheads in adding lots more Locale constants. Not to mention all sorts of compatibility issues due to countries changing names, etcetera. So, basically, they had to stop somewhere ... and the current set is where they stopped.

The other thing to note is that these constants are merely a convenience; i.e. a simple way to get Locale objects that you can always get by other means; e.g. by using a Locale constructor, or by calling Locale.lookup(...).

Is there a Java library which provide constants for locales?

AFAIK, no. And it seems to me like a bad idea, for the reasons above.

And, of course, you can always define your own class containing Locale constants that are convenient for your applications.


For the record, I found an RFE in the Java Bug Database (in the Google cache) that relates to this:

JDK-4399080 : RFE: java.util.Locale.SPANISH and java.util.Locale.SPAIN does not exist

This RFE was reported against Java 1.3.0, and was closed as "Won't Fix" with the following Evaluation:

We decided a while ago not to add more predefined locale constants. It's easy enough to write new Locale("es"); or new Locale("es", "ES"); so there's no real benefit in adding more constants - especially since it's not feasible to cover all languages and countries.

norbert.lindenberg@Eng 2001-01-05

Halifax answered 7/11, 2014 at 11:10 Comment(0)
M
5

Although "why" questions are open-ended, I think it's safe to say that the constants probably exist only for backward compatibility. Here is Oracle's article about Internationalization, specifically, the pre-constructed locales.

As you can see, the author freely admits that the provided constants do not cover all the "Important" countries (from whatever perspective that may be), and that they shouldn't be used at all.

The constants today are the same as they were in JDK 1.1, so I believe they are kept only for backward compatibility.

Mitziemitzl answered 7/11, 2014 at 11:20 Comment(0)
J
3

Why only some locales as constants?

It was really a mistake to make any locales constants (as RealSkeptic's answer shows). Countries are not constant. They come and go, and what was once a country may end up consigned to the history books and no longer commonly used (e.g. recently USSR, Yugoslavia). It would be a mistake to have a convenient Locale constant for a country that no longer exists.

You may say, "well so what, let's just put all countries in as constants, and if they cease to exist, where's the harm"? The problem there is that new countries also come into existence all the time (e.g. East Timor, Kosovo). Either new constants have to be continually added to the list, which would bring its own compatibility issues, or the constant list would remain (as it is now) frozen in time, representing only countries that existed when JDK 1.1 came out.

Junia answered 7/11, 2014 at 14:24 Comment(0)
E
1

Because Locales are not constant. Remember the episode of family guy where Peter founded the Country "Petoria"?

enter image description here

Exam answered 16/11, 2015 at 10:3 Comment(1)
@troig Yes, check out another creative question: stackoverflow.com/questions/55433978Exam
P
1

Locale.of

As others have said, just ignore the Locale constants. Their creation was a poor design decision made in the hectic rush to bring Java to market.

FYI, Java 19+ offers convenient static factory methods of.

Instead of Locale.CANADA (English in Canada), use Locale.of( "en" , "CA" ).

Instead of Locale.CANADA_FRENCH (French in Canada), use Locale.of( "fr" , "CA" ).

Instead of Locale.US (English in United States), use Locale.of( "en" , "US" ).

Instead of Locale.UK (English in the United Kingdom of Great Britain and Northern Ireland), use Locale.of( "en" , "GB" ). Note the GB, not UK.

Parakeet answered 20/7, 2024 at 20:47 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.