PR

Javaアプレットを高速化するための手法が充実してきた。クライアントをカスタマイズできる環境であれば,実用に耐えるパフォーマンスは出せる。ただし,JDKの非互換性のため,特定のJDKに縛られて利用せざるをえない。Javaアプレットの実力を再評価した。

 Write Once,Run Anywhere――。JDK(Java Development Kit)の互換性に悩むユーザーにとって,このキャッチ・フレーズは空しく響く。「試しにJDK1.1.5で作ったソースをJava2でコンパイルしてみたが,エラーや警告が山ほど出た」(クボタシステム開発 ビジネスシステムセンター ソリューションテクノロジーグループ ITチーム 日原偉氏)。これまでのJDKは,互換性への配慮が欠けている。

写真1●中京テレビ放送の予算管理システム
それまでは専用クライアント(UNIXワークステーション)を利用していたが,社員へのPC配布を機に,WWWブラウザからも利用できるようにした。システムの構築に当たっては,基幹業務をやる限り,入力したコードに対する複雑なチェックはクライアント側で行う必要があると考えた。そのため,HTMLでは無理だと判断し,Javaアプレットを選択した

 さらに,稼働環境であるJavaVMやJRE*の種類によって,アプレットの動きも違ってくる。そのためアプレットを利用するユーザーは,クライアント環境を統一し,特定のJDKの枠内でアプリケーションを開発するしかない。

 だが,非互換性の問題を差し引いても,アプレットの魅力は残る。それは,アプリケーションを容易に管理でき,しかも,操作性の高いGUIを実装できる技術だからだ。また,開発言語としてのJavaの将来性も買える。実際,最大の課題であるパフォーマンスの問題が工夫によって乗り越えられてきたことで,企業システムにじわりと浸透してきた(写真1[拡大表示])。

 さらに,HotSpot*といった新技術によって,アプレットのパフォーマンスや安定性は向上していく方向だ。そのため,「従来のC/Sシステム並みの操作性をブラウザに求めたが,HTML(HyperText Markup Language)だけでは無理だ」(中京テレビ放送 企画局システム開発部 参事 鈴木則泰氏)と判断するユーザーにとって,アプレットは見逃せない選択肢となる。

とにかく一発目を早くする

 Javaアプレットを利用するための技術上のポイントは大きく3つある。それは,(1)初期画面を表示する時間を短縮する,(2)アプレットを小さく作る,(3)アプレットを高速かつ安定して稼働させる――である(図1[拡大表示])。

 初期画面を表示するためには,アプレットをダウンロードする以前にJavaVMを起動する必要がある。そのため,この時間をいかに短くできるかが最初の課題となる。

 クライアントのJavaの実行環境は,ブラウザに装備されているJavaVMを使うほか,JREをブラウザにプラグインして利用する方法があるが,JREの方が起動時間は短いと言われる。例えば,中京テレビ放送では業務によってNetscape NavigatorのJavaVMとプラグインしたJREを使い分けているが,JavaVMの起動時間が約20秒であるのに対して,JREは約10秒で済む*1

 また,JavaVMの起動処理の内容をもう少し細かく見ると,JIT(Just In Time)コンパイラを起動するために多くの時間を費やしている。そのため東京海上システム開発では,「JITコンパイラが無くても,パフォーマンスに差が出なかったため,これを無効にしてJavaVMの起動時間を短くしている」(東京海上システム開発 開発第三部 技術開発グループ アシスタントマネジャー 小林賢也氏)*2

図1●Javaアプレットを業務システムに生かすためのポイント
ユーザーにとっては,初期画面が表示されるまでの時間の長さが最大のストレスとなる。JITコンパイラを無効にするなど,この時間を短くする方法はいくつかあるが,これらの方法はクライアント側に何らかの仕掛けが必要となる。反対に,アプレットを小さく作ることは,すべてのシステムに共通の課題である

クライアント・サイドで性能を稼ぐ

 JavaVMの起動が完了したクライアントは,サーバーからJavaアプレットをダウンロードする。アプレットはネットワークを転送されるため,このサイズをいかに小さくできるかが,ダウンロード時間を大きく左右する。

 初期画面の表示時間を短縮することだけが目的であれば,JARファイル(Javaのアーカイブ形式)をいくつかに分割しておき,必要最小限の機能だけを一発目にダウンロードすることも考えられる。また,いったんダウンロードしたJARファイルをクライアントに保管しておき,次回からはそのバージョンをチェックすることで,ダウンロードを省略する手もある*3

 このようにして初期画面の表示時間が短縮できるが,実は利用上の制約がある。これらの高速化手法は,クライアント側に仕掛けが必要になるのである。JREをプラグインする,JITコンパイラを無効にする,アプレットのバージョンをチェックする,といった工夫は,どれもブラウザ側にカスタマイズが発生する。つまり,社内システムのようにクライアントを管理できる環境でしか使えない。反対に,社外のユーザーを意識したシステムでは,クライアントをチューニングしないことを前提に開発するしかない。そういう意味では,アプレットをできるだけ小さく作ることが,唯一のチューニング・ポイントなのである。

重いコンポーネントを特定する

 では,どうすればアプレットを小さく作れるのか。アプレットを削るための狙い目は2つある。一つは,Java開発ツール独自のクラス群,もう一つはGU Iコンポーネントである。

 クボタは99年4月,協力メーカーと発注データをやり取りするシステムを稼働させた。Javaアプレットは各メーカーが所有するパソコン上で稼働させるため,前述したクライアント側の仕掛けが使えない。しかも,「メーカーの中には電話回線で利用してもらうユーザーもいるため,アプレットのサイズを最大でも35Kバイトに抑えた」(クボタ 機械製造本部 機械生産技術部 課長 中村公夫氏)。開発に当たっては主要なJava開発ツールを評価したが,「ツールを使うとどうしてもツール独自の大きなクラスが入ってしまうため,結局はJDKのみを使い,コアなJavaのクラスだけで作った」(クボタシステム開発 日原氏)*4

GU Iコンポーネントを選別する

 Javaアプレットの動作を軽くするためには,利用するGU Iコンポーネントも慎重に選ぶ必要がある。JavaのGU Iコンポーネント部品には,AWT*Swing*がある。SwingはAWTの表現力の不足を補うために登場してきたため,アイコンを付けたコンボ・ボックスといった高度なGU Iが実装できる。

 さらに,AWTがOSのGU I部品をラッピングしているのに対し,SwingはJavaだけで実装してあるため,一般的にはSwingの方がクライアントの負荷は低い。ただし,AWTはOSのGU I部品を使うがために,「同機能の部品をSwingとAWTで比較したが,動作速度はAWTの方が優れていた」(キリンビジネスシステム ビジネスサポート事業部 システム管理3部 山崎智裕氏)という意見もある。コンポーネントの数が少ないシンプルな画面であれば,AWTも選択肢になるだろう。

表1●Javaアプレットを利用するユーザーの例

 AWTとSwingのどちらを利用するにしても,機能によってコンポーネントの重さは違うため,選別して使うことが基本だ。例えばAWTを利用するキリンビールでは,LabelやChoiceといったコンポーネントが重かったため,独自にコンポーネントを開発して代用した(表1[拡大表示])。また,東京海上システム開発では,JBuilderが提供するSpinControlというコンポーネントが重かったため,テキスト・ボックスとボタンを組み合わせて同様の処理を実現した。

JDKを“枯れる”まで使い込む

 GU IコンポーネントがAWTからSwingへと進んできたように,Javaは今も進化の過程にある。現在の注目技術は新しいJavaVM「HotSpot」だ。HotSpotは,ガベージ・コレクションや性能を改善しているため,パフォーマンスや安定性の向上が期待できる。「HotSpot Client VM」は,Java2 Standard Editionのv1.3で入ってくるが,「実際にベータ版を試してみたが,Swingの動作速度や安定性の向上を確認できた」(日立中部ソフトウェア ソリューションサービス事業部 第2本部 アプリケーション開発部 柳生輝氏)。だが,Javaが進化してきても,ユーザーは簡単にはそのメリットを受けられない。なぜなら,Javaは2つの意味で互換性が欠けているからである。

表2●Javaの実行環境に起因する不具合と対処法

 その一つは,組み合わせ問題である。これまでもユーザーは,アプレットを高速,かつ,安定して稼働させるために,JavaVMやJREといった稼働環境の選択にかなり苦労してきた(表2[拡大表示])。

 JavaVMやJREは,メーカーやバージョンによって,特に画面回りの動きが異なる。そのため,ユーザーは自社のアプレットとマッチする最適な稼働環境を1つ選び,それをクライアントに実装して利用している。そのため,バージョン・アップなどで稼働環境を変更すると,アプレットとの整合性を再度検証しなければならないのだ。この問題は,見方によってはVisual Basic(VB)などのツールよりもやっかいだ。VBもバージョン間で非互換の問題はあるが,少なくとも1つのバージョンの中ではアプリケーションと稼働環境の整合性は取れている。これに対してオープンなJavaでは,組み合わせの整合性をユーザーが検証する必要があるからだ。

 さらにJavaの仕様にも,互換性の問題が潜んでいる。代表的な例はSwingのパッケージ名称だ。このパッケージのプレフィクスは,JDK1.1では「com.sun.java.swing」だったが,1.2では「javax.swing」に変わった。この問題に関して米Sun Microsystemsは,JDK1.1のSwingは拡張機能の位置づけだと説明するが,Swingを使ってきたユーザーにとってはたまらない。「再コンパイルして,検証する手間を考えると,そう簡単にSwingのバージョンを上げられない」(日立中部ソフトウェア 柳生氏)

 そのため,Javaのバージョン・アップに対するユーザーの姿勢は慎重だ。本レポートに登場したシステムは,稼働開始してからおよそ1年間が経過した。その間にJavaもかなり進化してきたが,「今回の開発でJDK1.1.5のノウハウがたまってきたので,次のシステムもこのJDKで作る」(クボタシステム開発 日原氏)というように,手放しで新バージョンに進むユーザーは皆無だ。現状では,いったん選択したJDKを使い込み,自社としての枯れた技術に変える覚悟がなければ,Javaアプレットによる企業システムの構築はおぼつかないのである。

(森山 徹=tmoriyam@nikkeibp.co.jp