About the Locale Sensitive Services SPI in Mustang Beta

Now that the Mustang (a.k.a. Java SE 6) beta is out (yay!), I think it is about time to describe one of the new i18n features so that you can ride the Mustang beta with pleasure. The feature I want to mention here has the name "Locale Sensitive Services SPI". Sounds complicated? No, it's not! OK, let me introduce it to you.

With this Mustang Beta release, we support more than 100 locales in java.text and java.util packages. Although this covers lots of areas in this Globe, there are areas that are yet to be supported by the Java runtime, and some customers do want them supported. Believe it or not, supporting a locale and its data requires a lot of investigation, such as the most popular date format or translation of a country name in that language. It's getting more difficult for smaller countries/regions. Sometimes even political ramifications come in. To resolve such a difficulty, there is an interesting project going on, which is called "Common Locale Data Repository (CLDR)" at the Unicode Consortium and standardizes the commonly used locale data. However, we cannot include all of the defined data into the Java runtime as it would bloat the Java runtime size (We introduced a couple of new locales in Mustang from the CLDR, though). So, the idea we came up with was to open up the interface with which the developers can plug in their own locale data and related services. I guess that the question in your mind now is, how do I use them, right?

To provide locale data/services, you first need to decide which functionality you want to provide for your own locale. With Mustang, you can provide the following functionalities by your locale data implementation.

  • java.text.BreakIterator
  • java.text.Collator
  • java.text.DateFormat
  • java.text.DateFormatSymbols
  • java.text.DecimalFormatSymbols
  • java.text.NumberFormat
  • java.util.Currency
  • java.util.Locale
  • java.util.TimeZone

Once you decide which functionality you want to provide with your locale, then you will need to implement the corresponding SPI (stands for the "Service Provider Interface"), which resides either in java.text.spi or java.util.spi packages. Let's say you want to provide a DateFormat object for a new locale, then you need to implement java.text.spi.DateFormatProvider. Since java.text.spi.DateFormatProvider is an abstract class, you will need to extend it and implement the following 4 methods.

  • getAvailableLocales()
  • getDateInstance()
  • getDateTimeInstance()
  • getTimeInstance()

You'll notice that "getAvailableLocales()" is actually derived from the parent class, i.e., LocaleServiceProvider, so all the SPI providers need to implement it so that the providers can "declare" which locales they claim "supported". And you will also notice that the other three methods are mirrored factory methods from the corresponding API class, i.e., java.text.DateFormat class. This means that the object which your implementation returns is passed down to the application as it is.

After implementing those required methods, then you need to package your implementations, so that you can deploy it with the Java runtime. Since the Locale Sensitive Services SPIs are based on the standard Java Extension Mechanism, you can package them as a JAR file (with a few tricks in its MANIFEST file, which can be found in here) and place it in the extension directory.

That's it folks. If an application requests a DateFormat object for your locale, your providers object is now created and used. Happy locale-adding!

Comments:

Post a Comment:
Comments are closed for this entry.
About

naotoj

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll