Java 7 Locale Changes
I admit that I haven’t been particularly active in the i18n or Java standards bodies in the last few years. Pardon me, but I had a wild rumpus in a startup for almost 3 years, then joined Yahoo for a couple years, and BAM! … during that time, the Unicode Consortium added emoji, and the Oracle Java folks overhauled the once relatively simple java.util.Locale class among other things. That’ll teach me to turn my back on those folks.
You can almost forgive the Unicode people for their addition of emoji… I just know that Ken Lunde had something to do with it but haven’t been able to pin the whole issue on him yet. 
[Just kidding people, just kidding Ken!]
BUT more interesting to me right now…have you seen java.util.Locale lately. What the heck happened there? Java 7 introduces Locale.Builder, Locale.Category, and a Locale.forLanguageTag method. With Java 7′s support of BCP 47 (the best practices for language coding), the Locale got a beefy new Builder inner class to help with…well, to help with building BCP 47 compliant locales. More on this in a different post. With the BCP 47 support, I suppose you might need the forLanguageTag method too. Now here’s what stumps me though — that Category class!
As far as I can tell, this category is to help you differentiate a locale instance for two different purposes: user interface language and locale-sensitive data formats. The new categories are the following:
- DISPLAY
- FORMAT
Do we really need a separate Category class to make that explicit?
Locale has another new method: setDefault(Locale.Category, Locale newLocale). I can’t wait to play with this a bit more. I suspect that this will set the default resource bundles (DISPLAY) for UI language and the default FORMAT for things like DateFormat, etc. However, I can’t understand why these two categories are actually needed in the platform libraries. Convenience maybe? You could always use two different Locale instances for this in the past, but I suppose this makes that easier? I’ll have to play around with these to find out more.
Come back again in a couple days after I look into this new Category and how it affects internationalization. I’m having fun discovering some of the new functionality and am eager to let you know what I find.
You’ve always had to use two Locales, but there was only one default locale. You had to create your own ‘locale framework’ to use instead of the default. Now, with a standard API, various libraries can keep locales in sync using that. I guess
Hi Sir ,
I would like to know how many Exception are present in the Exception class in JAVA SE 7. what is the exact count of all Exceptions. Please reply to this comment. i heard there were 33000 exception are listed in the JAVA 1.5 is it true? but my interest is in JAVA SE 7 count of Exception.
Thanks.
@Aniket Vidhate
Although I don’t know the exact count of all exceptions and errors that can be thrown in Java 7, you can easily find out all the Exception subclasses in the javadoc: http://download.oracle.com/javase/7/docs/api/java/lang/Exception.html
Personally I think that two is nowhere near enough. here’s the list of locale categories I have on my system:
LANG – presumably used as the default.
LC_MESSAGES – presumably what DISPLAY is set from, but being done incorrectly due to that bug in ResourceBundle which we have already discovered.
LC_NUMERIC, LC_TIME, LC_MONETARY – one of these three is surely used to get FORMAT, but which one? FORMAT covers all three kinds of format according to the Javadoc so what if my system is configured to use Australian numbers and dates but Japanese currency? This was a huge oversight by the Java class library devs.
LC_CTYPE, LC_COLLATE, LC_PAPER, LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_MEASUREMENT, LC_IDENTIFICATION – none of these are supported in any way at all.
At least having the Category API gives them a place to start adding the rest of these.
Yes! Finally someone writes about acommunity.
eu.