--単純なことのように聞こえるが。
その考えは改めた方がいい。すぐにJavaの複雑さが分かるだろう。
Javaは、さまざまな用途向けにさまざまな種類が存在する。初期の「Java Standard Edition」はパーソナルコンピュータ向けだった。それに加えて、データベース管理などのサーバタスク向けAPIを定義した「Enterprise Edition」、携帯電話でのテキストメッセージ送信などのモバイルタスク向けAPIを定義した「Micro Edition」が登場した。
複雑さはさらに増す。Micro Editionには、「Connected Limited Device Configuration」や「Personal Profile Specification」「Mobile Information Device Profile」「Mobile Information Device Profile 2.0」など、さまざまな種類があった。
結局のところ、プログラマーは特定のデバイスがどのAPIをサポートするのかを必ずしも予測できるわけではない。ある携帯電話はJava経由での2Dグラフィックスアクセラレーションをサポートするのだろうか。3Dグラフィックスはどうなのか。もしゲームを記述しているなら、これらの情報は重要だ。このような一貫性の欠如のために、キャッチフレーズを揶揄して「Write once, test everywhere(一度書いてどこでもテストする)」と言われることもあった。
最後の苦悩は「JavaFX」という形で現れた。JavaFXは、あらかじめパッケージされたOracleのソフトウェア基盤を使用することで、こうした混乱を一掃しようとした。しかし、JavaFXが登場しようとしていたころ、別の勢力がモバイルプログラマーの関心を引きつけた。AppleのiOSだ。
--Androidはこれにどう関連してくるのか。
携帯電話向けのJavaにはさまざまな欠点があるものの、SunおよびJavaと同盟関係にあったMotorolaなどの企業は、市場に適したテクノロジの構築に精力的に取り組んだ。また、そのクロスプラットフォームという利点は、広範にわたる新たなモバイルエコシステムを構築したいと考える人々にとって魅力的だった。
そのため、Googleとその同盟企業がAndroidのプログラミング基盤を探っていたとき、さまざまなデバイスが対象になる可能性のあるAndroidのスタート地点として、Javaが選択肢に挙がったのは自然な成り行きだった。実際に2005年には、いくつかの理由から、そのような計画になった。
Javaは、テクノロジ自体に加えて、プログラマーも大勢いた。つまり、Androidを対象とするプログラマーはゼロから始める必要がない。また、Javaを支持することは、Googleが同社モバイルOSの当初のライバルと想定していたMicrosoftに対する脅威にもなる。
しかし、Javaには付帯条件があった。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
ZDNET×マイクロソフトが贈る特別企画
今、必要な戦略的セキュリティとガバナンス
パナソニックのV2H蓄電システムで創る
エコなのに快適な未来の住宅環境
トラディショナルからモダンへ進化するBI
未来への挑戦の成功はデータとともにある