InfoQは先日，Cay Horsmann氏と対談する機会を得ることができました。そこで氏に，最近のJavaの状況や，最新の著書 Core Java, Volume 1 & Volume 2 第９版について話を聞きました。
1995年にオリジナルがリリースされて以来，言語仕様の拡張から，OracleによるSun Microsystems買収の一環としての所有権移行まで，Javaは数多くの変化を受けてきました。私たちの会話は，OracleによるJavaマネジメントの管理方法についての議論から始まりました。
InfoQ: これまでOracleが行ってきたJavaのマネジメントについてどう思いますか。言語の機能だけでなく，ビジネス面も含めてです。例えば彼らは，JREインストーラにサードパーティ製ブラウザツールバーをバンドルすることを決定しましたが，それについてはどのようにお考えですか。
Horstmann: ツールバーのバンドルについては納得できませんね。 Oracleのやり方には一貫性がないのです。一方でJavaを改善するために大量のリソースを投入しながら，もう一方でこのような残念なことをするのですから。セキュリティに関しても，彼らは長い間不手際を重ねてきました。今の状況は，その付けを払わされているに過ぎません。彼らの管理については，功罪相半ばするといったところでしょう。
それにOracleは，疑問の余地のある決定を行うときに，コミュニティとの議論をまったくしないのです。内部の関係者に話をしても，"今は手が離せない，何も言うことはない" としか答えてくれません。Sunの頃は，そんなことはありませんでした。彼らはいつでも，もっとずっとオープンでした。何かうまくいかないことがあったときでも，もっとよい仕事をしなければいけない，と快く認めてくれていたのです。でも多分，それがOracleの文化なのでしょうね。
InfoQ: つまりOracleは，解決策が見つかるまで問題を否定する，といった感じなのでしょうか。
Horstmann: 問題に対処するには，それがよい方法なのでしょうね。迷惑な話です。それにも増して，多くの人々の反感を買っているのが，Googleに対する訴訟の件です。
InfoQ: 本当にそうですね。Androidはある意味で，Javaプラットフォームの代表のような役目を果たしていると言えますから。GoogleがJavaを選んでくれたおかげで，Javaプログラマの需要も拡大しましたし，Javaのマーケットへの浸透も進みました。
Horstmann: まさにそのとおりです。しかもGoogleは，Sunから何らかのマーケットを継承した訳ではないのです。Sunも数年の間，Java ME(Java Platform, Micro Edition)フォンを何とかものにしようと訴え続けていた時期がありました。ですが，MEは消滅する運命にあると誰もが思っていましたし，スマートフォンという戦略もありませんでした。
InfoQ: あなたは単に著書をお持ちなだけでなく，コンピュータ科学を教える大学教授でもあるのですが，大学でのJava教育に関するニーズは，Androidの開発方法を学びたいという学生側からの要望によるものでしょうか。あるいはあなた自身の意思や，大学側の指示によるものですか。
Horstmann: そうですね，大学のコースに新しい言語を導入する場合，関連するコストが非常に大きいのです。それに，学生が新しい言語を十分かつ実用的に学ぶには，１学期の講義では足りません。ですからカリキュラムを作るときには，その中で取り上げるものを選択する必要があります。Javaの適用範囲には，非常に大きなものがありますから，最初は基本的なテーマから始めて，それからデータベースコースやネットワークコース，Androidならばもちろんモバイルコース，などのコースでそれを利用する，という方法が可能です。そのような理由から，私たちはJavaを非常に重視しています。それに私たちは，大学の役割は生徒に10の言語を教えるのではなく，いくつかの代表的な言語を使って概念を教えることだと思っています。私たちが指導しているのはJavaとC，関数型言語です。
InfoQ: モバイルコースではどのような言語を使っていますか。
Horstmann: 学生たちにはiOSの経験も積ませたいと思っています。彼らの半数以上はポケットにiPhoneを持っていますから，自分の携帯電話やApp Storeにアプリを置くことに関心があるのは自然なことです。Androidが50%，iOSが30%，残る20%がHTML5 (JQuery Mobile, PhoneGap) といったところでしょうか。
InfoQ: そのような比率に対して，学生の反応はどうですか。
Horstmann: 最初のうちは，複数の観点を得られることに喜んでくれました。それがとても有効なものだと思ったのです。しかし最終的には，大部分の生徒がAndroidの開発を選ぶようになっています。
InfoQ: Javaの将来はどこにあると思いますか - やはりAndroidが中心になるのでしょうか。
Horstmann: サーバ上，特に大規模なサイトでは，今でもJavaがたくさんあります。ただし最近のスタートアップ(新興)企業を見ると，多くはJavaを使っていません。彼らに特別な理由があるのかは分かりません。"(技術的な選択として) どうしてJavaを使用しないのですか" と聞いてみても，"いや別に，Javaのことはよく知らないから" と答えるだですから。この手の企業は，サーバサイドJavaを知らない世代の若者全体が占めている，ということなのでしょう。私のようなJava好きにとっては，ちょっと気掛かりな部分です。 それに，最新のJavaが開発環境として優秀であることを人々に伝えるという面では，Orcaleは充分な仕事をしているとは言えません。Javaはかつてのように，ロケットに使われるためのものではありません。今はJava EEも簡単に使えるようになっていますし，ツールサポートには素晴らしいものがあります。
InfoQ: スタートアップ企業にはJavaを "これだ" と思うようなセンスはない，ということでしょうか。
Horstmann: Oracleにどちらかといえば，高額なサービスを購入してくれる大企業を重視する傾向があるのではないかと思います。しかし革新的な企業の多くは，特にシリコンバレーでは，小規模な設備からスタートします。これらの人たちに話を聞くと，Railsを使っていたり，Node.jsを使っていたりしますが，サーバサイドJavaを使うことはほとんどありません。先ほども述べたように，必ずしも技術的な理由ではないのです。 時には彼ら自身，何が不足しているか知らない場合さえあるのです。
InfoQ: 最新バージョンのJava 7や次期バージョンのJava 8を見て，Oracleは "流行の要素" を取り入れようとしている，と思いますか。あるいは，サーバサイドでのメリットといった部分では，マーケット上の問題の方が大きいのでしょうか。
Horstmann: 確かに，サーバサイドJavaのマーケティングには問題があると思います。管理機能が充実していて扱いやすく，ツールも充実しているJavaのような言語にとって，サーバサイド開発は巨大なマーケットであるはずです。しかし，"みなさん，Javaをぜひ試してみてください。(人気があるように見えるテクノロジXを) 数年後に投げ出すくらいなら，Javaを始める方がずっと生産性が高いですよ" というような話を耳にしたことはありません。
InfoQ: まさにそのとおりですね。小規模サイトの問題は，アプリケーションが爆発的に成長しようというときに，彼らがNodeやRailsから "より本格的" な環境に切り替えるかどうか，という部分にあるように思います。
Horstmann: そうですね。それと，私が残念に思うのは，Java EEに対して不安感があることです。私自身は小さなプロジェクトであってもJavaを使用しています。結構短期間で開発できますし，さほど苦労もしていません。最近では，何百億のユーザにまでスケールするような仕事はなく，数千から数万のユーザを対象とするものがほとんどです。しかしその逆に，システムの規模に関係なく，無条件にRailsを使用するような人もたくさんいます。そうなると，Rubyを知っている開発者を確保しなければなりません。まったく新しいテクノロジを持った人が必要になるのです。それに比べれば，Javaの知識のある開発者を見つけるのはずっと簡単です。
InfoQ: 今の話は，現役の開発者に関するものですか，あるいは大学を卒業したフレッシュな人材についてでしょうか。
Horstmann: 大学卒の新人の話です。Javaは教育の現場ではユビキタスな存在です。しかし大学のコースからRubyを知っている人をさがすのは，独学であれ，仕事を通じた習得であれ，ずっと大変です。
InfoQ: Javaは時代とともに変わっていますが，それをどのようにご覧になりますか。
Horstmann: プログラム言語が生き残るためにば，今日の誰もが重要と見なす機能は利用できなければなりません。また現在のようにコンカレントなプログラム環境では，関数型のライブラリの必要性が高くなります。これはJava 8の機能がなければ実現できませんでした。素晴らしいことです。Scalaの機能と比べれば，確かにScalaの方が優れています。しかしScalaには，Javaよりも複雑であるという別の問題があります。
InfoQ: Scalaといえば，ScalaユーザはプラットフォームとしてJVMの恩恵を多分に受けている訳ですが，Javaを使おうとはしませんね。
Horstmann: 自分のしていることを理解しているなら，Scalaを使った方が生産性はよいでしょう。自分のアイデアを１ラインの半分以下のコードで表現できるのですからね。Javaでは面倒でとてもできないようなアプローチでも，Scalaなら簡単です。私もScalaは好きですが，その反面，時に恐ろしく思うこともあります。ひとつ間違った作業をすれば，しばらく頭を悩ませることになるからです。
Javaは概ねシンプルですし，一貫性があります。自分のJavaプログラムのステートメントが裏でどのように動いているのだろうか，と最後に悩んだのはいつだったか，思い出すことができないくらいです。これもまた重要な機能です。
InfoQ: 特に企業環境やチームで作業する場合は，少人数での開発よりも扱う規模が大きくなりますから，すべてを頭の中に留めておくことは難しいですね。予測可能性が必要です ...
Horstmann: 確かに。それと対照的なのがC++ 11です。言語の規模が大きすぎて，そのすべてを理解するのは大変です。
InfoQ: Rubyのような言語についてはどうでしょう。つまり，すぐにプログラミングを始められるような ...
Hosrtmann: Ruby自体は，それほどはっきりした方向性を持った言語ではありません。コードの統制を保つのはRailsの役目です。何日も頭を悩ませそうなRubyの難問があったとすれば，Rubyに熟達した技術者ならこんな風に言うでしょう。"ああ，２年前ならこんな感じで動いただろうけれど，今はこうしなくてはいけないよ。"
InfoQ: Javaにも，Ruby on Railsを模倣したフレームワークがいくつかあります。これらはRuby on Railsの優れた機能と同じくらい効果的なのでしょうか。Javaの採用を促す存在になると思われますか。
Horstmann: Railsの解決した問題の多くは，今日ではもう解決する必要のないものです。この点に注意してください。ユーザインターフェースがモバイルデバイスやタブレット，あるいはHTML5を通じたクライアント上にあって，クライアント上の描画をJavaScriptで行っているのなら，RailsのHTMLテンプレートは無用なものでしょう。ですから，Railsが今後もこれまでのように成長を続けられるか，という点は疑問ですね。
InfoQ: なるほど。ところで，あなたの著書を読み返してみたのですが，限られた文書の量でJavaを説明するのに，どのような工夫をされているのでしょう。現在は２分冊で構成されていますが，どの程度のサイズであれば言語全体をカバーできると考えていますか。取り上げる内容は，どのように決めているのでしょう。
Hosrtmann: 最初はすべてを網羅しなければならなかったので，本のサイズもかなり大きなものになりました。何年も前に初版がデザインされた頃，皆が知りたがっていたのはSwingについてでした。その次がRMIでした。それがこのスタイルにしようとしていた，最後の版だと思います。次のJava 8版では，開発者が本当に知りたいものに集中しなければならないだろうと思います。とは言っても，集中する対象がSwingになることはあり得ません。もちろんRMIも。これらを最後に使ったのはいつのことでしょうか？
InfoQ: 本書を読むと，言語全体をカバーしていることから，これが初版ではないことがはっきり分かります。新たな開発者やJavaユーザにもこれらの情報は役に立つのでしょうか。あるいは彼らは，Volume 1しか読まないでしょうか。
Horstman: 半数以上の人たちは，すでに紙の書籍を持っていません。本書のセールスがどこから来ているかを見ると，その大部分がSafari Books Online経由であることが分かります。プログラマの皆さんはそこへ行って，数ページを読んでみてください。
InfoQ: サイズは問題にならない，ということですね - ですが私の質問の意図は，書籍としての構成を維持する上で問題があるのではないのか，ということです。読者は必要な部分だけを抜き取ればいいのですから，サイズを問題にはしないでしょう。
Horstmann: 確かにそうです。もし次版でSwringが取り上げられなくても，Safariには前版も引き続き置かれると思いますから，そこで終わりということではありません。セールスの電子コピー版への移行が早かったことは，私にとって本当に素晴らしいことです。コンピュータ科学のマーケットではここ暫く続いていることですね。
今後はやめようと思っていることのひとつは，部分的な理解のできないような長い例題の掲載です。書籍によってはすべての章で，このような例題を掲載しているものもありますが，次から次へと例題を積み上げると，途中から読み始めるのが極端に難しくなってしまいます。
私の本はどこからでもアクセス可能なようにしています。ですから興味のある章あるいは節に移動して，それまでの６章を読まなくても内容をフォローすることが可能です。
InfoQ: すでにJava 8の先を見据えているという話がありましたが，今後必要な，あるいは議論の対象にするべき機能は，どのようなものだと思いますか。
Horstmann: まずは間違いなく，ラムダですね。コレクションライブラリの変更も重要です。共通的な処理がずっと簡単になるはずです。それから，並列性の修正も重要なことです。プログラムを複雑にすることなく，マルチコアのメリットを活用できるようにしてほしいですね。Java 8とScalaなら，これは見事に動作します。プログラマなら，"ああ，これを全部，並列で実行したい" と思うことがあるでしょう。並列的なビューを用意して，その中でLinq風のクエリを実行して，並列処理を自由に扱えるのです。この部分は，非常に重要なものになると思います。
InfoQ: プリミティブ型は取り除く必要があると思いますか (リサーチの際に意見の共通性があるようでした)。
Horstmann: その方がいいでしょうね。何年か前，この問題に当時取り組んでいたNeal Gafter氏と話したことがあります。プリミティブ型が原因でジェネリック全体の複雑性のレベルが上がったとき，なぜこれをやらなかったのか，と氏に聞いたところ，intとIntegerを同一視できない理由があるからだ，という答でした。Integerオブジェクトを new Integer(42) のように生成して，ロックに使っている人がいるというのです！この場合，２つの new Integer(42) インスタンスを区別できなければ，そのコードは壊れてしまうでしょう。
しかし，後方互換性を絶対的に保証していくというのは無理な話だと思うのです。intとIntegerは当然ながら交換可能であってほしいですし，この区別はVMがプログラマのために最適化できるものであるべきです。
同じように，int配列とInteger配列を変換するにも，VMはかなり難しい仕事をしなければなりません。
今になってみれば，整数値や浮動小数点値は最初からオブジェクトにしておくべきでした。しかし20年前にはプリミティブ型がとてもよいアイデアに思えたのです。
InfoQ: Javaが初めての学生を指導する場合でも，Integerがあるのだから，という理由でそちらを使用するのでしょうか。
Horstmann: いいえ，intを使用します。たくさんのライブラリで使用していますから。この違いに多くの時間を割くようなことは，実際にはありません。コレクションではラッパクラスについての考慮が必要ですが，実際のところ，それは大した問題ではありません。ArrayListに整数値をたくさん詰め込むような処理は，現実にはそれほどありませんよね？
結局のところ，JavaをしてJavaたらしめているものを考えた場合，２つのものがあると思います。ひとつは，博士号がなくても理解可能なブルーカラー言語である，ということです。もうひとつは常に巨大なライブラリが存在していた，ということです。何をしようとする場合でも，大抵はJavaライブラリがすでに存在しています。
これほど広範なライブラリを持った言語はそれほど多くありません。例えばPythonは素晴らしい言語ですが，Javaに比べれば，Pythonのライブラリはごく限定的なものです。
Pythonに関してもうひとつ言えることは，Javaの後方互換性の恩恵が非常に大きい，という点です。Python 3の規則性とエレガントさは称賛に値しますが，Python 2が長く使われているのにも驚きます。両方持っておく，というのは気分のよいことではありませんね。
InfoQ: 大量のレガシコードを持っていると，問題かも知れないと ...
Horstmann: Scalaは冷淡ですね。作っているものを6ヶ月ごとに壊されて，やり直しを強いられているような感覚です。
InfoQ: そうなんですか。そんなことがよくあるのですか。
Horstmann: ええ，ですからある時点が来たら，このやり方は止めなければならないでしょう。しかし現時点では，Scalaはバイナリ互換でないので，全部を再コンパイルする必要があります。言語の仕様変更があまりに多いので，プログラムの修正が必要になる可能性も多くなってしまうようですね。
InfoQ: 言語の発展には望ましいが，使う側にはそうではない，ということですね。
Horstmann: そうです。ですから彼らは，ある時点になったら "オーケイ，もう十分に楽しんだから，今度は安定させなければ" と言わざるを得なくなるでしょう。
InfoQ: なるほど。ところでJavaを全体として見たとき，もしこの言語の管理を任されたとしたら，克服しなければならない最大の障害は何でしょうか (取り除くにせよ，改善するにせよ)。
Horstmann: おそらくプリミティブ型でしょうね。複雑さを大幅に助長するという意味で，本当に迷惑な存在です。その他に本当に取り除きたいものがあるか，ということですか？考えたことがありませんね。実際のところ，Java言語にはそれほど問題はありません。ただし起動時間が遅いのには閉口します。そのおかげで，Javaはスクリプト言語として使用することができないのです。しかもこの件に関しては，何の対処もされていないように思えます。 Oracleがモジュール化でこの問題に対処してくれればと思っています。Java 9か，あるいは孫の時代にそれを見られるといいのですが。これは言語の適用範囲の制限に関わる問題です。
言語自体ではなく，むしろ環境に関するものとしては，他にもセキュリティの問題があります - 必要なクライアントJVM更新をOracleができなかったために，Javaはユーザを失ってしまいました。Flashのセキュリティ問題に対して不満が出ないのは，Adobeが3週間毎に新バージョンの取得方法を示してくれるからです。しかし私のWindowsマシン上のJavaの場合，電源を入れる度に更新の必要を示す小さなアイコンが表示されるのですが，それをクリックしてもエラーメッセージが表示されるだけで，何も起こらないのです。何年も経っているのに，彼らはこの問題をまだフィックスできていません。
InfoQ: その２つをそのように比較することは，考えたことがありませんでした。よい指摘ですね。AdobeのアプローチがJavaランタイムよりも優れている，ということですね。
Horstmann: そうです。クリックするだけで，Flashが更新されるのです。しかしJavaではうまく行きません。動作しないのです。私の見たところ，どの学生のマシンにも，古いバージョンのJavaの痕跡がいくつも残ったままになっています。
InfoQ: アクティブな開発者なら，何がインストールされていて，それが適切かどうかを見るのは簡単なことなのでしょう。しかしそれをリモートで診断するとなると，混乱を起こすことになるかも知れませんね。
Horstmann: そのとおりです。それに，首尾よく診断ができたとしても，平均的なユーザにどんな対処方法を伝えられるでしょう？"いい機会だから，ハードディスクを再フォーマットしませんか" とでも？
InfoQ: 他に変更したい部分はありますか。
Horstmann: そうですね，できが悪いという理由でなくすべき言語機能を質問されているのであれば，ラベル付きbreakのように，決して使うことのない機能がいくつかあります。これらはない方がいいでしょう。削除すべきだと言うのは，余計な複雑さを軽減するためです。ただし使用しなければいいのであって，別に邪魔になる訳ではありません。しかしそうではなくて，Javaのデザインの話であれば，特に削除してほしいというものはありません。機能追加に関して言えば，Javaにあるといいな，と私が切望しているのがプロパティです。getterやsetterを書くのが嫌なのです。
世界の飢餓を救うほどのものではありませんが，同じコードを繰り返し書かなくてよいのはありがたいですね。Scalaで私が気に入っている部分のひとつも，簡単なクラスであれば数行で記述することができることなのです。
InfoQ: Javaで批判の的になっているボイラープレート型のコードに対処する訳ですね。
Horstmann: そうなのですが，もう少しはっきりさせておきましょう。Javaは新たなCobolであると言う人がいますが，Javaが生まれた頃のCobolの状況を思い出してみてください。Cobolは当時，まさに死の瀬戸際にありました。私は今でも，プログラマの半数以上がCobolで仕事をしていた頃を覚えています。でもその数年後には，誰もCobolを使っていませんでした。この移行は実に，実に速いものでした。そしてJavaについては，今でもJavaに可能なことで，他に同等なものがない機能がたくさんあると思います。特にワールドクラスのポータブルな仮想マシンはそうです。このような理由から，Javaはもうしばらく生きながらえるだろうと思っています。
もうひとつとして，Cobolの寿命が尽きたということは，それに置き換わるだけのよいものがあった，ということになります。そこで言いたいのは，現時点で人々が熱狂するようなよいものとは何か，ということなのです。つまり，他に "ハレルヤ" を叫びたいようなものがないのです。
InfoQ: そうですね，まさにそのとおりだと思います。他の言語についても見てみたいのですが，例えばC++です。C++は現在も自らを活性化し続けていて，これがC++の世界の中でもっとも注目を集める部分になっているようです。
Horstmann: それを使ってコーディングしてみたいですか？
InfoQ: C++経験者の目には非常によいものに写るかも知れません。ですが，新しい開発者の興味を十分に引き付けられるかどうか，それは分かりません。C#について見れば，多くのユーザはJavaより優れていると感じています。しかし一方で，MicrosoftがC#を無視して新たなテクノロジに走るのではないか，と心配している開発者も少なくありません。
Horstmann: すべての意図や目的の面で，C#はJavaです。Javaにない機能もいくつかありますが，重要なものは少しの間でJavaに実装することができます。
InfoQ: それらの中に，Java開発者が大挙して乗り換えるほどのものがあるかと言えば，そうは思えません。C#のユーザはそれで満足でしょう。ですが，そう，ほとんどの陣営はすでに分割しているのです。 新しい開発者は，そこから来るのではありません。もしここですべての - 少数派，という言葉を軽蔑的な意味で使いたくないのですが ...
Horstmann: ニッチ，でしょうか？
InfoQ: そう，異なるサイズの，異なる競合部族の言語です。
Horstmann: そうですね，その意味で行けば，すべてを支配する言語というものは存在しません。現れるかも知れませんが。もし見つけたら，私に連絡ください。次の本を執筆したいと思います。
InfoQ: 新しい言語がいくつもあって，そのうちのいくつかは少なくとも，低いレベルでは普及していますが，本当の意味で広範な支持を得るには至っていません。今はどの言語にも批判や擁護する人たちはいますが，本当の意味でのマニアや，強く推奨する人はいないようですね。
Horstmann: 難しい問題ですね。 つまり，もはや言語だけの問題ではないのです。現在では，適当なサイズのライブラリが求められます。仮想マシンも必要です。言語がマシン上で直接動作する時代は終わったのです。Objective-Cのような言語では望めなかった最適化が，VMを使えば可能になります。JavaScriptの性能が飛躍的に上がったのも，仮想マシンの開発に力を入れた結果です。
InfoQ: まるで２つの大きなプールがあるようですね。ひとつは，静的タイプを持った計画先行型の言語。もうひとつは "できるだけ早く，さっさと書きたいんだ" というもの。オーバーラップする部分はありますが，共通点はもはやありません。
Horstmann: それもよい指摘ですね。静的タイプの言語には多くの機能があると思います。GoogleがDartで行っていることを見てください。彼らは静的タイプと動的タイプを橋渡ししようとしているのですが，これはなかなか興味深いやり方です。でもそれが，すべての人々にとって，次世代言語の候補になり得るでしょうか？私はまだしばらく，Javaが強い立場を保つだろうと思っています。
InfoQ: ですがJavaはここしばらく沈黙していて，新技術の担い手としては停止状態にあるようにも思えます。ご存知とおりJavaはアプレットから始まり，大きなブレークスルーのようになりました。それに続いたのが，おそらくオリジナルのWebアプリバックエンド，そして今はAndroidです。Javaにはいつでも，言語を前進させる立場になるチャンピオンが存在していたように思います。
Horstmann: Javaが長期にわたって使用されてきた理由としては，他にもオープンソースであることや，特許が期限切れになるまで間もないということもあります。その美徳のひとつである特許については，何を言ったとしても - 20年という期間は最終的には終了するのです。
InfoQ: それが次のチャンピオンになるのかも知れませんね。今日は本当にありがとうございました。改めて感謝します。
Horstmann: はい。ありがとうございました。
回答者について
Cay S. Horstmann氏は 'Core Java Volumes 1 & 2', 'Scala for the Impatient' (Addison-Wesley, 2012) の著者であり，'Core JavaServer Faces' 第３版 (Prentice Hall, 2010) の共著者でもあります。サンノゼ州立大学の教授で，Javaチャンピオンでもある氏は，開発者向けカンファレンスでも数多く講演を行っています。