when a locale isn't a Localethere was a recent discussion concerning using farsi (persian) language with cf. my first reaction was to point out that farsi locales (fa_IR iran and fa_AF afghanistan) weren't supported java locales, so that was that.
at about the same time there was an announcement on the icu4j mailing list about the next version being built on CLDR data. so i asked if that meant that we'd be able to make use of all the "new" locales in CLDR like farsi, etc. one of the icu4j guys (steven loomis) replied "yes" and further pointed out that icu4j 2.8 was already making use of icu4c's locale data. further discussion with steven helped debunk one of my long held misconceptions, that a java "locale" was a real world "Locale" (ie. the locale bundled up with all it's attendant resource data such as day/month names, etc.). "Locales are just identifiers" says steven, "duh!" says i. while it's convenient to think locales == Locales, formally in java "locale" refers to the identifier and not the data.
so what? what that means, if you're using icu4j for your i18n work (and you should), is that you have access to all the nifty locales that icu4j has no matter what core java supports (or doesn't support in this case). so something like this becomes possible (and easy):
aDateFormat = createObject("java","com.ibm.icu.text.DateFormat");
which produces: Persian (Iran) دوشنبه، ۱۸ اکتبر ۲۰۰۴
note that the core java getDisplayName method falls back on "Persian (Iran)" which while not perfect is better than nothing. icu4j 3.0 ULoclae class would actually produce the correctly localized name.
the more i work with icu4j, the more impressed i am with how well-thought it is. it really is the bees' knees for i18n work.
thanks to steven for enlightening me.