Thursday Jul 02, 2009

JavaFX 1.2とインプット・メソッド

JavaFX 1.2の機能と拡張(英語)の一つとして、インプットメソッドを扱うAPIが加わりました。JavaFX 1.2以前のリリースでは、シーングラフ中のNodeはインプットメソッドで確定された文字列のみを一連のKeyEventとして受け取る事しかできませんでしたが、JavaFX 1.2で新しく加わったAPIを使う事によりNodeはインプットメソッドの変換途中の文字列の情報も受け取れるようになり、アプリケーションが自由に変換途中の状態を表示できるようになります。

JavaFXでインプットメソッドがどのように動作するかという全体のデザインは、JavaのInput Method Frameworkとほぼ同様になっています。特に何もしない場合は(上に書いた通り)、Nodeは変換結果のみをKeyEventとして受け取りますが、NodeTextInput mixinをextendして実装した場合、インプットメソッドの変換途中の状態がアプリケーションが定義したonInputMethodTextChanged()InputMethodEventとして通知されます。簡単なコードサンプルを以下に示します。このクラスはCircleのサブクラスでInputMethodEventを受け取れるサンプルです。


class InputMethodCircle extends Circle, TextInput {
    override var onInputMethodTextChanged = 
        function (e:InputMethodEvent): Void {
            println(e);
        };
}

このサンプルはInputMethodEventが通知されるごとにコンソールにその内容を書き出します。

InputMethodEventには4つの変数があります。node変数はどのNodeでこのイベントが起きたか、composed変数は変換途中の文節を表すInputMethodTextRunのシーケンスを持ち、committedは確定文字列、caretPositioncomposedテキスト中のキャレット位置をそれぞれ表現しています。アプリケーションは通常InputMethodEventを受け取るとcomposedInputMethodTextRunにあるそれぞれの文節を指定されたInputMethodHighlightに応じて表示、committedで返された確定文字列をアプリケーションのテキストに挿入、また caretPositionで指定された位置にキャレットを表示します。

以下はInputMethodEventの内容を表示する別の簡単なサンプルです。サンプルの一行目にあるカラーサンプルは、それぞれの文節の色が示すアトリビュートを示しています ("U-R"が"unselected raw"ハイライト、"S-C"が"selected converted"といった具合です)。上にあげたサンプルよりもちょっとだけ視覚に訴えるようにしてみました。

もしお使いのOSにインプットメソッドがインストールされていない場合、Javaで書かれたインプットメソッドを使ってこのサンプルを試す事もできます。Javaインプットメソッドの使い方は 昔の記事を参照ください。

しかし、もしもあなたのアプリケーションでこの様な詳細な部分まで必要ない場合はどうすれば良いのでしょう?大丈夫。TextBox UIコントロールはこれらの仕組みを既に内部で実装しているので、TextBoxを使えばそれ以上何もしなくていいでしょう。

JavaFX 1.2 and input methods

One of the Features and Enhancements in JavaFX 1.2 is the API for dealing with input methods. Prior to the JavaFX 1.2 release, Nodes in a scene graph can only receive the result of the input method composition as a series of KeyEvents. With the new API introduced in JavaFX 1.2, Nodes can directly receive the input method composition information and do whatever they want with it.

The overall design of how the input methods work in JavaFX is pretty much analogous to the Input Method Framework in Java itself. By default, Nodes receive only the result of the input method composition through KeyEvents (as noted above), but once they extend the new TextInput mixin, then they are able to receive the whole input method composition information through the new InputMethodEvent, delivered in the user defined onInputMethodTextChanged() function. Here is a simple example of a Circle subclass that receives InputMethodEvent:


class InputMethodCircle extends Circle, TextInput {
    override var onInputMethodTextChanged = 
        function (e:InputMethodEvent): Void {
            println(e);
        };
}

The above code dumps the contents of InputMethodEvents to the console, whenever they are delivered.

An InputMethodEvent contains four variables, i.e., node on which this event has occurred, composed which is a sequence of InputMethodTextRun that represents the text in composition, committed which is the result of the composition, and caretPosition which designates the caret position inside the composed text. On receiving InputMethodEvents, applications would typically display the composed text with the visual feedback according to the InputMethodHighlight in each InputMethodTextRun, insert the committed text into applications text, and display the caret as suggested by caretPosition.

Here is another simple example that displays the contents of InputMethodEvents, with the color scheme shown at the top of the application ("U-R" denotes "unselected raw" highlight, and "S-C" for "selected converted" and so on). A little visualized version than the one above.

If you don't have input methods on your underlying operating system, you might want to try out input methods written in Java. How to use them are described in my old article.

HOWEVER, if you do not want to deal with such details, don't worry. The TextBox UI control is your friend. It has a built-in implementation for such behavior, so use it in your application and you can just call it a day :-)

Monday Jan 26, 2009

文字列リテラルのローカリゼーション記法がJavaFX Script言語リファレンスに。

JavaFX 1.0がリリースされてから既にしばらく経ちますが、ようやく"##"シンタックスについてのセクションをJavaFXランゲージリファレンスに追加できたのでblogでご紹介します。リファレンスの"String"タイプの章の"Localization of String Literal"の部分がそれです。基本的に以前紹介したプロポーザルのままです。

もし何かお気づきの点がありましたらコメントまで。

String literal localization in JavaFX Script Language Reference

It's been a while since JavaFX 1.0 was released. Now I finally had some time writing up a section in the JavaFX language reference about the "##" syntax. Take a look at the "String" type, and look for the section named "Localization of String Literal". It's basically based on the contents of the original syntax proposal.

If you have any comments, please leave them in this entry comment area. Thanks!

Tuesday Feb 12, 2008

JavaFX Scriptの「より簡単な」ローカリゼーション機能

前回のエントリーで、JavaFX Script言語の文字列リテラルの簡単なローカリゼーションの提案について説明しました。現時点でその実装が OpenJFXコンパイラリポジトリにコミットされたので、実際にどう動いているかをみてみることができます。例としてこのリポジトリにあるJavaFXBallsというデモを日本語にローカライズしてみました(このローカリゼーション自体もリポジトリに入っています)。

左下のボタンのテキスト、「ストップ」がソースコード上どうなっているかというと、ボタンのオブジェクトリテラルを作っているところのコードは:

text: bind if (not test._is_running) then ##"Start" else ##"Stop"

で、それに対応するJavaFXプロパティファイルのエントリーは:

"Stop" = "ストップ"

これだけ、です。

さて、今現在考えているのは、この機能をソースコードの文字列リテラルのローカリゼーションだけではなく、より一般的なローカリゼーション機能として使えないかということ。例えばJavaFXのランタイムライブラリとして、javafx.util.StringLocalizerというクラスを作り、その APIで、

package javafx.util;

public class StringLocalizer {

    public attribute key: String;
    public attribute locale: java.util.Locale;
    public attribute packageName: String;
    public attribute propertiesName: String;
    public attribute defaultString: String;

    // this is lazily bound to the above attributes.
    public function localizedString(): String;

    public static function associate(packageName: String,
                                     scriptFileName: String,
                                     properties: String): Void;
}

としたらどうでしょう。これらのAPIを使うことにより、次のようなことが可能になるはずです。

// ローカリゼーションオブジェクトの作成。
var localizer = StringLocalizer{ key: "Hello, World!" };

// "Hello, World!"のデフォルトロケール用の翻訳を出力。
System.out.println(localizer.localizedString());

// "Duke"のデフォルトロケール用の翻訳を出力。
localizer.key = "Duke";
System.out.println(localizer.localizedString());

// "Duke"のフランス語の翻訳を出力。
localizer.locale = Locale.FRENCH;
System.out.println(localizer.localizedString());

// "Duke"のフランス語の翻訳を、"foo/bar/MyBundle_fr.fxproperties"
// から探してきて出力。
localizer.packageName = "foo.bar";
localizer.propertiesName = "MyBundle";
System.out.println(localizer.localizedString());

また、"associate()"スタティック関数を使うことにより、JavaFX Scriptのソースファイル(またはJavaFXのパッケージごと)をJavaFXプロパティにマップすることができます。これにより文字列リテラルのローカリゼーションを探すプロパティファイルを指定できるようになります(デフォルトではソースのJavaFX Scriptファイルと同じ名前・場所のJavaFXプロパティファイルから探します)。このスタティック関数を使うことで、アプリケーションのプロパティファイルをどのようにパッケージするかを柔軟に指定できるようになるのです。一つのプロパティファイルで全アプリケーションのローカリゼーションを保持するか、ソースファイルごとにプロパティファイルを持つか、あるいはその中間か、など。

これはまだまだアイディアの段階で、実際にコミットするときにはもっと洗練されていると思いますが、この機能によって「より簡単に」JavaFX Scriptのローカリゼーションが可能になれば、と思っています。

\*Easier\* localization in JavaFX Script

In the last blog entry, I explained the proposal for an easy way to localize string literals in JavaFX Script language. Now the implementation for it is in the OpenJFX Compiler's repository, let's take a look at this feature in action. As an example, I localized the JavaFXBalls demo into Japanese (it's in the repository as well):

You see the text in the button at the bottom left corner reading "ストップ", which means "Stop". In this button's object literal creation, the source code looks like:

text: bind if (not test._is_running) then ##"Start" else ##"Stop"

And it's JavaFX properties file entry is simply:

"Stop" = "ストップ"

Now, we are planning to extend this string literal localization proposal into a generic string localization runtime library function. Suppose that there is a JavaFX runtime library class, e.g., javafx.util.StringLocalizer, and it has the following APIs:

package javafx.util;

public class StringLocalizer {

    public attribute key: String;
    public attribute locale: java.util.Locale;
    public attribute packageName: String;
    public attribute propertiesName: String;
    public attribute defaultString: String;

    // this is lazily bound to the above attributes.
    public function localizedString(): String;

    public static function associate(packageName: String, 
                                     scriptFileName: String,
                                     properties: String): Void;
}

With these utility APIs, you could do something like:

// Object creation
var localizer = StringLocalizer{ key: "Hello, World!" };

// This prints localized text for "Hello, World!" for the default locale
System.out.println(localizer.localizedString()); 

// This prints localized text for "Duke" for the default locale
localizer.key = "Duke";
System.out.println(localizer.localizedString()); 

// This prints localized text for "Duke" for the French locale
localizer.locale = Locale.FRENCH;
System.out.println(localizer.localizedString()); 

// This prints localized text for "Duke", from 
// the FX properties file "foo/bar/MyBundle_fr.fxproperties
localizer.packageName = "foo.bar";
localizer.propertiesName = "MyBundle";
System.out.println(localizer.localizedString()); 

Also, with the "associate()" static function, you could associate a JavaFX Script source file (or a javafx package) to a JavaFX properties file so that the string literal localization consults the associated JavaFX properties file for searching the localized text. (By default, the JavaFX properties file with the same name/location as the source file is searched). This static function would provide developers with the granularity of how the JavaFX properties files are packaged. You could provide one single JavaFX properties for your entire application, or one properties file for each source script file, or in between.

This is still a rough idea and needs to be refined. But I'd hope this would contribute to an \*easier\* localization in JavaFX.

Thursday Jan 10, 2008

JavaFX Scriptの簡単なローカリゼーション機能

またまたしばらく間が空いてしまいましたが、ここ最近はずっとJavaFX Scriptの国際化についての仕事をしています。JavaFX ScriptはJavaをベースにしたスクリプト言語なわけで、もちろんJavaに本来備わっている国際化に関する機能はすべて使えるわけですが、JavaFX ScriptからいちいちJavaの機能を呼び出して国際化関連のことを行うのはスクリプト言語らしくないし、さらにJava言語とJavaFX言語が混在してバグの元になりかねません。そこでJavaFX言語の仕様策定中ということもあり、その中に入れてしまいたいのがリテラル文字列を簡単にローカライズできる仕組みです。ある文字列をローカライズする場合、Javaでは普通、

    import java.util.ResourceBundle;

    static final String GREETINGS_KEY = "HELLO_WORLD";

    String greetings;
    try {
        ResourceBundle rb = ResourceBundle.getBundle("foo.bar.resources.My_Resource");
        greetings = rb.getString(GREETINGS_KEY);
    } catch (MissingResourceException mre) {
        greetings = "Hello, World!";
    }

の様に書くと思いますが、いま模索中なのがGNUのgettext()関数のように、引数となる文字列がそのままデフォルトの翻訳になるような仕組みです。上のコードをそのシンタックスで表記すると、

    var greetings = ##"Hello, World!";

たったの一行。シンプルでしょ?ここで"##"はリテラル文字列に働く単項演算子のような役割をします。この演算子がつくと実行時にこのリテラル文字列"Hello, World!"をキーとして適当な翻訳を探します。お気づきの方もいると思いますが、PropertyResourceBundleはホワイトスペース' 'をデリミタとして解釈するため、実は"Hello, World!"はキーとはなり得ないんです。そこで提案したいのがJavaFX Script用の新しいリソースバンドルのフォーマット。このフォーマットは単純に次のようなフォームを取ります。

    <JavaFX string literal> = <JavaFX string literal>
e.g.,
    "Hello, World!" = "こんにちは、世界!"

さらにボーナスとして考えているのは、このFX propertiesのデフォルトのエンコーディングを"UTF-8"にしようというもの。これで今まで頭を痛めてきた"ISO-8859-1" & native2asciiの呪縛から解放されるでしょう。他のエンコーディングを指定したい場合は、ファイルの頭にCSS形式のエンコーディング宣言(@charset "<IANA defined charset name>";)を入れてあげればそれに従うようにします。

ただこの方式には問題が一つあり、スクリプト内に同じリテラル文字列があり、それぞれ別の翻訳をさせたい場合(例えば2つの"File"というリテラル文字列をそれぞれ名詞、動詞として翻訳したい場合)に困ってしまいます。この問題を解決するためにオプションとしてキーを明示的に指定できるようにしました。#[FILE_NOUN]"File"のように、大括弧でくくって明示的なキーを指定します。

まあこんな所ですが、プロポーザル(英語です)とプロトタイプ実装をPlanet JFX wikiに置いてみたんで、どうぞおためしください。それとコメント、感想もよろしく!

Easy localization in JavaFX Script

I've been recently working on the internationalization of the JavaFX Script, which is a scripting language based on Java. Although all the Java internationalization features are definitely available from JavaFX Script program as it runs on top of a Java runtime, it would not be very scripting language like, and could be error prone because of the complexity of mixing Java and JavaFX. One of the features that I would like to have in the JavaFX Script is an easy way to localize strings in the JavaFX source. In Java, it's like:

    import java.util.ResourceBundle;

    static final String GREETINGS_KEY = "HELLO_WORLD";

    String greetings;
    try {
        ResourceBundle rb = ResourceBundle.getBundle("foo.bar.resources.My_Resource");
        greetings = rb.getString(GREETINGS_KEY);
    } catch (MissingResourceException mre) {
        greetings = "Hello, World!";
    }

Instead, we are thinking of a new easier way to localize strings in the JavaFX Script. It would be pretty much like GNU's gettext() function where the key itself becomes the default translation. So the above code would be written in JavaFX Script like:

    var greetings = ##"Hello, World!";

Yep, just one line. How simple is that! Here "##" works like a unary operator to the string literal, in which it looks for the proper localized string with the key of "Hello, World!". Some of you might notice that PropertyResourceBundle recognizes a white space ' ' as the delimiter, so "Hello, World!" cannot be a key in it. You are correct. So what we would like to provide is a new resource bundle format for the JavaFX script. It simply accepts the form of property as

    <JavaFX string literal> = <JavaFX string literal>
e.g.,
    "Hello, World!" = "こんにちは、世界!"

In addition as a bonus, this FX properties file's default encoding is "UTF-8" (yay!) and yet also accepts the CSS style encoding declaration (@charset "<IANA defined charset name>";)

There could possibly be an issue of ambiguous meaning for short words. For example, "File" could both mean "to file" and "file (as a noun)". To address this situation, you can optionally insert an explicit key which will be used for resource look up. This optional key can be specified within a pair of square brackets, e.g., ##[FILE_NOUN]"File".

I wrote a proposal and prototype implementation at Planet JFX wiki, so you might want to try it out. Comments are welcome as I'd like to know what you think!

Thursday Jun 28, 2007

JDK7でのCurrencyクラスの機能拡張

JDKのアプリケーションで通貨に関連したことを行おうとした場合、通常はjava.util.Currencyクラスを使います。このクラスを使うと、ある国で使われている通貨や、その通貨のローカライズされたシンボルがなんであるかを調べることが出来ます。このような情報を提供するためにJDKは内部にISO 4217標準に基づいた通貨のデータを持っています。ところがこのISO 4217のデータ、いろんな理由(たとえばデノミネーションとか)でしばしば管理機関によってアップデートがかかるんですが、JDKで持っている通貨のデータを常にこのISO 4217のデータに合わせておくことは通貨を扱うアプリケーションには非常に重要です。もし実際の通貨とJDKの通貨データに整合性がない場合、これらの金融アプリケーションのトランザクションに重大な問題が生じるからです。(前に書いたトルコのお菓子のエントリーが良い例(すいませんが英語です)かも)

さて、現在のJDKの通貨サポートの問題点の一つに「通貨データが"lib/rt.jar"の中にクラスファイルとして存在している」というのがあります。なぜこれが問題か。というのもISO 4217のデータに変更があった場合(例えばスロベニアがユーロに移行したとか)、常にrt.jarをアップデートしなければなりません。この事実はたとえばお客さんが通貨データだけをアップデートしたい時でも、常にJDK全体をアップグレードしなければならない事を示しています。TimeZoneのデータも同様な位置づけにあるんですが、TimeZoneのデータは既に隔離されていて、個別にアップデート可能になっています。

で、このブログエントリー、何を言いたいかというとJDK7ではこの問題はもう起こらなくなります。というのも必要な変更のチェックインをつい最近完了したんで、もうしばらくするとOpenJDK経由でアクセスできるようになるはずです。変更後では通貨データは"<JAVA_HOME>/lib"の下に"currency.data"というバイナリファイルとして個別に置かれます。なのでJDKアップデートリリースとは別のサイクルでこの通貨データをアップデートすることが可能になるはずです。さらにボーナス機能として、ユーザーがプロパティファイルでこの通貨データの内容を上書きすることも出来ます。"<JAVA_HOME>/lib/currency.properties"というファイルを作って、その中に"key=value"というペア("key"はISO 3166国コード、"value"は3文字通貨コード、3桁数値コード、それにマイナー・ユニットをカンマで区切った物)を書いておけば、"key"で指定した国の通貨のデータを上書きできます。たとえば"JP=JPZ,999,2"というエントリーは、日本の通貨データを上書きします。

この通貨の拡張に加えて、いくつかのAPIも実装しました。まず初めはJDKで定義されているすべてのCurrencyインスタンスを列挙する機能:

public static Set<Currency> getAvailableCurrencies()

それからISO 4217の数値通貨コードを取得する機能:

public int getNumericCode()

最後にCurrencyインスタンスのディスプレイ用の名称取得機能。例えば日本の通貨は、getSymbol()すると「¥」ですが、このAPIは「日本円」を返します(ロケールが日本の場合)。

public String getDisplayName()
public String getDisplayName(Locale displayLocale)

このAPIの最初の実装は英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、中国語(簡体字)、スペイン語、スウェーデン語、それに中国語(繁体字)の10のロケール用にローカライズされた通貨のディスプレイ用名称を返すことが出来ます。

さらにこれに応じてjava.util.spi.CurrencyNameProviderにも新たなSPIを追加しました。上記10言語以外に対応したい場合に、このSPIを実装することでどんな言語にもローカライズ可能です。

public getDisplayName(String currencyCode,
                      Locale displayLocale)

以上が今回実装した拡張の概要です。これで開発者の皆さんの苦労が少しでも減ると良いんですけどね。今回実はデモも一緒に載せたかったんですが、さすがにまだ出回ってないビルド用のデモは載せられないんでパスです。あしからず。

Currency enhancements in JDK7

In the JDK, applications can use java.util.Currency class to deal with currencies. They can query what currency is used in a given country, or what localized symbol is used for that currency in a particular locale. To provide applications with those currency information, the JDK contains the currency data that is based on the ISO 4217 standard. From time to time, due to a variety of reasons, the ISO 4217 data are often updated by the maintenance agency. Keeping up with these updates in the JDK is critical for applications that deal with currencies, such as a banking application. Otherwise, those applications would result in a wrong financial transaction (cf. see my old entry regarding the Turkish pastry story here)

Now, one of the issues in the current JDK's currency support is that the currency data is embedded in "lib/rt.jar" as a class file. So every time the ISO 4217 maintenance agency releases a currency update, such as Slovenia switching to Euro currency, the rt.jar file needs to be updated. This makes it impossible for customers to replace just the currency data portion when needed, without upgrading the whole JDK. This issue is analogous to the TimeZone data being separated from the JDK class files, and they can be upgraded separately.

The purpose of this blog entry is to announce that this will no longer be an issue in the JDK7, as I have just checked-in the necessary changes for this issue (woohoo!), which will soon be public in the OpenJDK build. In the new structure, the currency data is separately placed in "<JAVA_HOME>/lib" directory as a binary file "currency.data", which can be replaced not in sync with the JDK update release schedule. One added feature to this is that you could even provide your own properties file to override the contents in the currency data file. If you create a properties file as "<JAVA_HOME>/lib/currency.properties", which contains "key=value" pairs where the "key" is a ISO 3166 country code, and the "value" consists of three-letter currency code, three-digit numeric code, and the minor unit (separeted by a comma), it would override the currency data for that country designated by the "key". For example if it has "JP=JPZ,999,2", this would override the Japanese currency data.

Also, along with this Currency enhancement, I added a couple of new APIs. First one is to acquire all the available currencies in the JDK as follows:

public static Set<Currency> getAvailableCurrencies()

Next one is to return a numeric ISO 4217 code for a Currency instance:

public int getNumericCode()

The last one is to return the display name for a Currency instance. Instead of getSymbol() returning "$" for the US Dollar ("USD"), this API returns "US Dollar" in the "US" locale.

public String getDisplayName()
public String getDisplayName(Locale displayLocale)

The initial release of this API contains localized currency names for 10 locales, i.e., English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, Swedish, and Traditional Chinese.

I also added an SPI in java.util.spi.CurrencyNameProvider for the languages other than the above, so that one could provide localized display names in any language:

public getDisplayName(String currencyCode,
                      Locale displayLocale)

These are the changes that I have checked in, and I hope this is useful for developers. I would have liked to provide a working demo, but it's not possible to do it with a yet released build :-)

Sunday Apr 22, 2007

Ubuntu 7.04 「Feisty Fawn」

Ubuntuの新しいリリース、7.04 「Feisty Fawn」にJava 6が入っていると聞いていたんで、国際化関係はどうなっているのか興味がありました。ということで早速手持ちのEdgy EftをFeisty Fawnにアップグレード。そして下のエントリーにもあるLocale Demoを走らせてみました。

お見事! 日中韓のフォントはそのまま表示されるようです! Ubuntu開発者の皆様ありがとうございます。ところでこのLocale Demoですがちょっと変更を加えてみました。来月開催されるJavaOneのデモ用にぱっと見でJDKに含まれているロケールか、あるいはCLDRロケールかがわかるように先頭に小さいアイコンを付けてみました。今年のJavaOneのパビリオンに設置するデモマシンにインストールする予定ですので、よかったらお立ちよりください。

Ubuntu 7.04 (Feisty Fawn)

I know that Java 6 is included in the recently released Ubuntu 7.04 (Feisty Fawn), and am curious how they modify Sun's JDK6 in terms of internationalization. So I upgraded my Ubuntu from Edgy Eft to Feisty Fawn, grabbed the sun-java-6 package, and ran my locale demo...

Voila! CJK fonts seem to be supported out-of-the-box! Kudos to Ubuntu developers! BTW, I slightly modified the demo to display a small icon in front of each installed locale, so that it can identify itself as JDK bundled one or CLDR one. I am preparing to include this demo in one of the machines at this year's JavaOne Pavilion.

Wednesday Mar 21, 2007

JDK6の新しい国際化機能についての記事

今現在はテクニカル・ライターとして活躍しているJohn O'Conner、以前一緒にJavaの国際化チームで働いていたチーム・メイトでしたが、このたびJDK6での新しい国際化機能についての記事を書いてくれました。その記事はつい最近ここにアップロードされましたが、いろいろなサンプルとともに国際化の新機能を詳しく・わかりやすく紹介しています。

New article about the new internationalization features in JDK 6

John O'Conner, who used to work with me, wrote a really nice article about the new internationalization features in JDK 6. The article is just released here, which includes lots of examples demonstrating the new features.

Kudos to John!

Tuesday Nov 14, 2006

自分のマシンで試してみよう!

”百聞は一見にしかず”ということわざがありますが、前のエントリーで取り上げたロケール・デモをWebStartアプリケーションにして、実行可能にしてみました。

このデモはJava 6の機能を使うのでJava 6がマシンにインストールされていることが前提条件です。もしまだの場合はこの際ここからインストールしましょう。Java 6のインストールが完了したら下のボタンを押してみて下さい。

デモが立ち上がったでしょうか?この状態だとこのデモに表示されているロケールのデータはJava 6に同梱されているそのままです。"Locale Names"のタブへ移動すると実際にいくつのロケールがインストールされているかを見ることが出来ます。全部で"150"と表示されるはずです。

次に例のCLDRアダプターをインストールしてみましょう。CLDRアダプターはここにあるので、この"cldradapter.jar"ファイルをJavaランタイムの拡張ディレクトリに保存します。ウィンドウズですと通常、"C:\\Program Files\\Java\\jre1.6.0\\lib\\ext"というディレクトリがあるはずですのでここに保存します。そして再び上の"Launch"ボタンを押してみましょう。どうですか?今度は少し立ち上がりに時間がかかったと思いますが、これはロケールデータをユニコード・コンソーシアムのウェブサイトから動的にダウンロードしているためです。先ほどのように"Locale Names"のタブに移動すると、"365"個のロケールが表示されていると思います。

このデモの面白いところは、ロケールデータを"オン・デマンド”で引っ張ってきてくれるところです。Javaランタイムにもともと組み込まれていなくても、必要になった時に初めてインストールすることによって、ダウンロードの最適化及び拡張性を同時に得ることが出来ます。次期Javaのリリース(えっと、Java 6の次の話をしています :-)のプランの一つにロケールデータを如何に効率よくデプロイするかというフィーチャーがありますが、このデモはそれに対する一つの方向性を示していると思います。

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