2回にわたってJ2SE 5.0で実現されたAutoboxing/Unboxing機能について紹介した。そして、Autoboxing/Unboxingは便利な機能だが、従来と比較して実行速度が向上するものではないから注意するべきだという話にも触れた。今回からは、Autoboxing/Unboxing機能がどのように実現されているのかという背景を紹介し、J2SE 5.0で導入されたEoDがどういった仕組みで実現されているのかを説明していこう。

利便性導入の反対側にあるもの - 互換性の確保

Javaプログラミングをもっと直感的で簡単にする目的で導入された機能がEoDである。前回までは、EoDの最たる例としてAutoboxing/Unboxing機能を取りあげた。今回から数回にわたってその裏側を探ってみたいと思う。

EoDは、従来からのJavaプログラマには朗報だ。これまで問題視されていた点が改善されているのだから、嬉しい話だろう。EoDはJavaプログラマ一年生にとっては2つの側面がある。

1つはEoDのおかげで奇怪であったり難しいソースコードを記述しないで済む、というよい面だ。その一方で、言語仕様に統一性のなさが加わるわけだから、見通しが悪くなってしまい、言語に対する深い理解が難しくなる、という負の面もある。

また、Javaアプリケーションを利用するユーザの立場で考えてみると、EoDは従来のJava実行環境との互換性という問題が出そうだ、と考えるかもしれない。EoDを導入することでJavaプログラマには利点がある。しかし、このことでJavaアプリケーションを使用するユーザに不利益がでるかもしれない、つまり、J2SE 5.0で開発されたアプリケーションを実行するには、必ずJ2SE 5.0の実行環境が必要です、ということになるんじゃないかということだ。

J2SE 5.0で導入されたEoD機能は、この問題を巧みに回避している。後方互換性を保ちつつも、EoDの導入にも成功しているのだ。反面、Autoboxing/Unboxing機能で触れたように実行速度自体が高速化したわけではないという側面があるわけだが、このあたりは常にトレードオフの関係にあるといえる。

EoDがどのようなやり方で実現されたのか紹介する前に、まずJavaの実行方法の話をしておこう。

Javaの実行方法

プログラミング言語は、実行する方法によって、おおざっぱに2種類に分けることができる。コンパイラ型とインタプリタ型だ。

コンパイラ型は、ソースコードをあらかじめその環境で実行できるバイナリ形式のファイルに変更するもので、実行速度が高速になるという特徴がある。反面、別の環境にコピーしても使用できないし、同じ環境でもバージョンがかわると使用できないことが多いという欠点もある。

インタプリタ型は、そのソースコードを実行するためのプログラムが別途用意されていて、そのプログラムがソースコードを読み込んでその場で実行するというものだ。実行速度は期待できないことが多いものの、環境が違っていても実行するプログラムさえ移植されていれば実行できるため、環境間での互換性が保ちやすく、プログラミング自身も簡単なことが多いという利点がある。

Javaは、双方の折衷的な作りになっている。コンパイルもするが、インタプリタのように実行するのである。

コンパイル型とインタプリタ型には、それぞれ利点と欠点がある。双方の特徴を組み合わせれば、中途半端になってしまうものの、双方の利点を合わせたようなものが作れる。Javaがまさにそれだ。後発の.NETテクノロジーやC#言語でも同じ方法が採用されている。最近流行りの手法だといえるだろう。

どういうことかというと、Javaはいったんソースコードをコンパイルするにはする。ただし、生成されるバイナリファイルは、そのままでは実行できない。生成されたバイナリファイルは、Java仮想マシンと呼ばれるプログラムによって、まるでスクリプトやインタプリタ言語のように解釈され実行される。あらかじめコンパイルするため、実行速度の向上が期待できる。実行用のプログラムで解釈して動作させるのだから、その実行用プログラムさえ移植されていれば、どの環境でも実行できる。このおかげで、実行速度と環境間の互換性という2つの課題に対処しているのだ。Java仮想マシンがセキュリティにも対応し、規定されている以上の動作はとれないという安心もある。

この方法はいいとこどりではあるが、万能ではない。技術は常に開発されているので、実行速度も向上しているし、移植された環境も増えている。しかし、やはりその環境を記述するために作成されたプログラミング言語で開発されたプログラムの方が高速に動作することが多いし、実際問題、インタプリタ型言語の方が簡単に習得できる。しかし、優れた方法ではあるのであり、今後のプログラミング言語の一つの方向ではある。

互換性ということ

ここで問題となるのが、互換性である。Javaはインタプリタとしての特徴も備えているから、以前のバージョンでコンパイルされたバイナリファイルは新しいバージョンで実行できるのか、その逆はどうなのか、といった、バージョン間の互換性という問題が持ちあがってくる。

バージョンが変わったのなら、実行する環境のバージョンも変更しなければならない。基本的には同じバージョンで開発と実行はおこなうものだ。

しかし、そうも言ってられない事情もある。やむなく別バージョンでも動作させなければならないこともあるし、バージョンごとに互換性がないと今後の展開が気分的にも不安だ。前後のバージョンで互換性が低ければ、JavaユーザはうんざりしてJavaから離れただろう。そんなわけで、Javaは後方互換性が高くなっている。以前のバージョンでコンパイルされたバイナリは、新しいバージョンでも実行できなければならない。

しかし、実行環境に大幅な変更を加えてしまえば、互換性が保ちにくくなってしまう。かといって、要望を取り入れないわけにもいかない。そこで、どのような形で機能の取り込みが行われたかといえば、以前のバージョンで理解できる形式にソースコードを変換してからコンパイルするという方法だったのである。

今回は話が少々抽象的になってしまった。次回からはこの仕組の詳細について具体的にみていこう。

提供: 毎日就職ナビ

学生のための就職情報サイト「毎日就職ナビ」。4,000社以上の新卒採用情報が常時掲載され、社内の雰囲気が伝わる情報画面、さまざまな項目での会社検索、エントリーや説明会検索など、機能も充実。無料適職診断、就活Q & A、エントリーシート添削講座など、就職活動に役立つ記事も満載です。研究者、エンジニアを目指す学生の方々も是非エントリーしてください。お待ちしています!

毎日コミュニケーションズ 就職情報事業本部はプライバシーマークを取得しています。