Javaのリスク考察 2018年版

Java10以降、Java SEのリリースサイクルを6カ月単位とすることが発表されてしばらく経ち、また、予告通りJava11からいよいよJavaのサポート体制も変更となった。

本稿ではJavaを使い続けるリスク、あるいはほかの言語ランタイムを使い続けるリスクについて検討してみたい。プログラム言語は用途に応じて様々なものが使い分けられている。特に本稿では選択肢が多く、またJavaのシェアも高いサーバーサイドのWebシステムという戦場で検討してみたい。

「Javaリスク」という単語、語呂が良い

— なぎせ ゆうき (@nagise) 2018年10月11日

pic.twitter.com/tBGvupxtJ4

— rf (@rf0444) 2018年10月11日

ランタイムの有償化リスク

無償で提供されていたプログラム言語のランタイムが、突如有償化するリスクをまず考えてみよう。この点で、Javaはもっともリスクが低い部類であると言える。

JavaのランタイムはGPLライセンスで公開されており、無償でソースコードが公開されている。GPLライセンスは、ソースコードの公開が求められ、また改変を許可し、オリジナルもしくは改変版の複製と頒布が許されるが、その派生物もGPLを求める。なので、独自にJavaを改造・拡張したモノを作ることも許されているが、そうした派生物はソースコードを公開しなくてはいけない。重要なポイントはこれらの「複製と頒布」は有償でおこなっても良いという点である。

ただ、こうした派生物は通常は「Java」を名乗ることができない。これは、GPLライセンスの話ではなく、商標の話となる。特段珍しい話ではなく、改造したものが本家の名前を名乗ってかんばんを乗っ取るというのはできない、というだけの話である。ただし、JavaはOracleの定める手続きに則り互換テストをクリアしてOracleと契約すれば「Java」のかんばんを掲げることができる。

繰り返しになるがGPLのポイントとしては、バイナリ頒布にあたっては無償を強制しない。ソースは無料公開されるが、自分でビルドして実行形式を作るところができないのであれば、誰かの作ったバイナリを求めることになる。ここで有償サポート版のバイナリを購入しても良いし、誰かがビルドして無償で公開してくれるものに期待しても良い。バイナリを有償化で配ろうとも、ソースコードは無償で公開されることがライセンス上保証されている。頒布も自由だ。仮にどこかのサポートの値段がたとえ高騰することがあったとしても、常に誰かが無償ビルド版を作って公開する権利が保証されている。

また、本家がメンテナンスをしなくなったEOL(End of Life)の過去版についても、どこかの誰かがセキュリティアップデート版を作ったのであれば、GPLの波及によりソースコードを公開することになるだろう。リリースサイクルの変更に伴いサポート期間が憂慮される点はあるが、独自にサポートすることを表明している企業もある。こうした際にも、GPLというライセンスは安心感につながる。

Javaに関して言えば、Oracle以外もJavaランタイムを出している個所は有償無償ともに複数ある。Oracleはずっと昔から有償サポートを出し続けてきた。Java11でOracleは有償版だけの機能をいくつかOpenJDKに譲渡し、無償化された。
そしてOracleがいままで出してきた無償版の役割はOpenJDKに移管された。

JavaはSun Microsystemsが開発し、のちにOracleがSunを吸収合併してOracle管轄のものとなった。2010年のことである。OpenJDKの歴史はそれより前の2006年までさかのぼる。OracleがSunを吸収合併したわけだが、OracleはOpenJDKの存在も、JavaがGPLライセンスであることも、分かったうえでJavaを手にしたのだ、ということは把握しておきたい。

競合相手は？

JavaがGPLなのはわかった。ではほかの言語ランタイムはどうなのであろうか？

環境	ライセンス	開発元
Java	GPL系	Oracle他
PHP	BSD系 (PHPライセンス)	The PHP Group
Ruby on Rails	BSD系 ※1	Rails Core Team
Python	BSD系(Pythonライセンス)	Python Software Foundation
C#	BSD系(MITライセンス)	Microsoft
Node.js	BSD系(MITライセンス)※2	Node.js Developers
Swift	Apache-2.0	Apple
Go	BSD系	Google
scala-native ※3	BSD系
Kotlin/Native ※3	Apache-2.0

※1 RubyはBSDとRubyライセンスとのデュアル、RailsがMITライセンス
※2 Node.js自体はMIT、JSエンジンはGoogle V8 JavaScript Engineだと修正BSD
※3 いずれも通常のScala / KotlinはJava VM で動作させるが、あえて脱Javaを考えるケースでの比較としてscala-native / Kotlin/Nativeを記載した

個々のライセンスの詳細に踏み込むと大変なのでざっくりとした記載としている。BSDライセンスは自由な改変・再配布・無保証といったところである。GPLとは違い、派生物のライセンスへの波及はない。Apacheライセンスも似たようなものであり、改変も再配布も自由である。派生物のライセンスへの波及もない。もちろん、これらのライセンスも無償を強制しない。

ライセンスという観点で見れば、いずれの環境も、オープンな状態に置かれている。

オープンソースな言語ランタイムの有償化戦略

さて、有償化リスクを検討するために逆に「どうすれば有償化できるか？」について考えよう。GPLにせよ、BSDにせよApacheライセンスにせよ、有償で配布することそのものを否定するライセンスではない。しかし、ソースコードが公開であっても、自分で実際に動く状態のバイナリファイルをビルドするというのはなかなかやる人はいない。なので、バイナリを有償配布するという戦略は常にとることができる。全てのユーザーに金を払わせることはできなくても、一部の人はビルドの手間賃だと割り切って払ってくれるかもしれない。

しかし、いずれのライセンスも、自由な再配布を許しているので、誰かがビルドして無償配布することを防ぐことができない。こうした「有志による無償版」は一定以上の言語ユーザーがいれば必ず作られるだろうと思う。

有償サポートとセキュリティアップデート

現実的には、サポート契約が有料というのが実際に行われていることである。

本家の通常版ではすでにEOL(End of Life)となっている古い古いJava7であるとか、Java6であるとか、さらにもっと前であるとかのバージョンについて、もしセキュリティ上の問題が生じたらコードを修正したバージョンを提供しますよ、といったものである。

Javaは比較的後方互換が厚い言語であるが、完全というわけでもない。過去のある時点でつくられたシステムを新バージョンで動かして何かあったらどうする！という理由で古いバージョンのまま有償サポートを受けて使い続けているという現場は結構ある。そこに金をかけるならバージョン追従にお金を使った方がシステムが長持ちするんじゃないかという気もするが、出来上がった時点でスパゲティコードなシステムなら、敢えて長持ちさせる必要もなく、時がたったら作り直せばいいやぐらいに考えているかもしれない :-P

作り直すときに「過去の仕様を全て再現すること」とか言い出して、過去の問題ある動きを頑張って忠実に再現するような話もあったりなかったり。

話がそれた。古いバージョンのJavaに対する有償サポートは昔から行われていることである。しかし、このセキュリティアップデートのコードもGPLであるから無償で公開されているという点は重要なポイントである。BSD系やApacheライセンスでは、それこそこうしたコードを非公開で高値でふっかけることだって可能なんだから。

バージョンアップの際の締め出し

次に、よく言われる陰謀論であるところの「無償で行きわたらせ、容易に抜け出せなくしてから突如有償化して金をせしめる」について考えてみよう。

まず、オープンソースの状態で行きわたっている言語ランタイムが、ある日突然動かなくなる、ということは、まずない。そうした、時限式の締め出しをするコードが公開されているコード中に見つかったら、それは事件だし、もしそのようなものが見つかれば、その時限爆弾を排除した改変版が出回ることだろう。このとき、商標権といったかんばんの都合上、おなじ名前を名乗り続けることはできないかもしれないが。

ライセンスは契約なので権利者側の一方的な通告で過去の契約を変えることはできない。なので、すでに頒布してしまっている過去版を金を払わないなら使うな、と言うことはできない。完全に有償化するとしたら、あるバージョン以降、ライセンスを変えてオープンソースではなくしてしまうか、あるいは、ソースは公開しても二次利用した改変版を自由に作れないようなライセンスにしてしまうことだ。

GPLにせよ、BSDにせよApacheライセンスにせよ、自由な改変と再配布ができてしまうので時限爆弾を排除した改変版が出回るのだ。自由な改変と再配布ができないライセンスにしてしまえば、そうした改変版は非合法の「海賊版」となる。合法的に使いたければ必ず金を払え、とさせることができるようになる。

過去のライセンスは変えられないにしても、新バージョンからライセンスを変更することは可能である。しかし

なおライセンス条件を別のものに変更する場合には、対象となっているソフトウェアの著作権者全員が、ライセンスをその別のライセンスに変更することに同意していることが必要です。そのため、リナックスカーネルのように、無数のプログラマーがコミットしている場合には、全員の同意を取り付けるのは非常に難しいですから、ライセンスの変更は事実上不可能でしょう

多数のコミッターが参加しているようなプログラミング言語についていえば、権利的に突然の変更というのは難しいのではないだろうか（参加するにあたってこのあたりの権利を処理するためのなんらかの同意書がとられているかもしれない）。JavaはOracleが商標をもっており、開発を主導してはいるがOracleによる独裁政治でつくられているわけではない。

いささか古い記事で申し訳ないが（おそらく2011年の記事）Javaの仕様策定プロセスJCP（Java Community Process）とそのメンバーについて

• https://www.oracle.com/technetwork/jp/database/articles/pickup/index-1838236-ja.html
• https://www.jcp.org/en/participation/members

つい最近も、このJCPのExecutive Committee（JCPの運営方法などを決める評議会）の委員を選出する選挙が実施されましたが、投票の結果、「SOUJava」というブラジルの Javaコミュニティが選出されました。このように、Javaは現在も、特定のベンダーが支配することのない、オープンなコミュニティで開発が進められて いるのです。

といったことが語られている。

こうした民主的なプロセスが作られているプログラミング言語の場合、独裁的で強硬なライセンス変更は難しいだろう。

ライセンス変更に対するコミュニティの対応は

この時点ですでにだいぶん「アリエナイ」話になっているが、仮に仮に仮に独裁的で強硬なライセンス変更がされたと仮定しよう。この時に、コミュニティはどうするだろうか？

言語ランタイムの開発が少数によってなされているようなケースでは、ライセンス変更後の対抗版というのはなかなか出てくるものではない。強硬なライセンス変更を行った中央に囲われていない人材で、無償版が作られるかはわからないし、すくなくとも大きな停滞期となるだろう。

もし、開発コミュニティが十分に大きく、強硬なライセンス変更を行った中央に囲われていない人材も多数いるような状況であれば、ライセンス変更がされる直前のソースコードをもとに、以降のバージョンが作られ、クローズドな有償版とオープンソースの無償版に分裂していく可能性がある。しかし、オープンソースの無償版が作られるというのは、いささか楽観的な未来予測と言える。

GPLライセンスは派生版もGPLであることを強要するが、BSDライセンスやApacheライセンスは強要しない。GPLライセンスである言語ランタイムは、こうした分裂があったとしても、派生版がGPLであることは保証している点で少しばかり安心感が増す。もっとも、「独裁的で強硬なライセンス変更」という前提となる仮定がまずもってアリエナイものであることは強調しておく。

たとえ、プログラミング言語の追加機能ようなバージョンアップがされないにしても、セキュリティアップデートがされるぐらいにメンテナンスされるのであれば現在その言語ランタイムを使っているプロジェクトが、直ちに立ち往生することはない。それでも、オープンソース版の発展がみこめないとなると、その猶予をもって別の言語ランタイムへの乗り換えが図られることだろう。発展が見込まれる程度にメンテナンスされるのであれば、利用し続けることも可能であろう。

言語のランタイムがオープンソースであれば、別の実装を作ることは容易である。たとえ、言語仕様がISOなどで規格化されたような言語であっても、オープンな実装がなければ、それを作ることは労力的に難しい。（規格化されていれば、個別に権利者と取引しなくとも言語規格をクリアしたことを名乗れるという効果はあるが、作る労力は別の話だ）もちろん、独自に実装しなおしたものであれば、互換性が保たれるかも疑問である。
ランタイムがオープンソースである、派生することができるという状態に置かれていること自体が、ある種の保証であるといえよう。

開発を主導するもの

プログラミング言語のような、相応に大規模で複雑で難易度の高いものを作るというのは、並の労力ではない。作れる人材も限られるが、そうした人材の労力をこれでもか、と投じなければ作り上げることはかなわない。そうした人材の趣味の時間に頼っていては難しく、そうした人材が言語開発に没頭できる環境、つまり、彼らが言語を開発することで暮らしていけるようなサポートがされなければ、なかなか言語の発展がすすまないだろうと言える。

そうした暮らしのサポート、いうなればマネタイズまでもが、言語開発者個々人任せというのは少ない人材をさらに少なくする。そういう意味で、言語開発に企業がスポンサードしているというのはマンパワー的にも大きい。しかしながら、企業のスポンサードというのは大抵ひも付きである。スポンサーの意向というのが関与してくるものである。そして、スポンサードしている企業が傾いたとき、言語ランタイムは危機を迎えることになる。

これは、2010年のSun Microsystems が Oracle に吸収合併されたときに懸念されたリスクである。その時代はJavaの停滞期であった。2006年12月11日にJava6がリリースされてから、2011年7月28日にJava7がリリースされるまで実に4年半もの停滞を迎えたのである。

JavaがOracleに移管されてからJavaの仕様策定プロセスであるJCPといった民主的な体制が敷かれたのもSunという中心企業が傾いた際のリスクを痛感したからであろうか。これは私の想像に過ぎないが。もし仮に、今後OracleがJavaを手放すようなことが起きるとしたら、その時はSunからOracleに移行した時よりも混乱はずっと少なくて済むのではないかと思う。

こうした主導企業の停滞のリスクは、Microsoft が擁するC#や、Appleが擁するSwiftでも考えられる。もっとも、この2社がそう簡単に傾くとは思えないが。また、企業によるスポンサードがないプログラミング言語についていえば、もっと端的に中心メンバーが引退するリスクを負っている。実際のところ、世の中の小規模オープンソースプロダクトなんてものは、中心となる一人が離れてしまえばぱったりと更新が止まったりするものである。急に盛んに更新されるようになったな、と思えば後継者となる人物が現れた、といった調子である。

個人の力によるところが大きい世界であるからこそ、そうしたリスクが目立つ。うまく組織化できているプロダクトは安心感が強く、スポンサードの含めてリスク分散されていることがより望ましいと言える。

言語ランタイムのリスク

さて、いくつか検討してきたが、

• Openになっていない言語ランタイムは突如の有償化と締め出しのリスクがなくはない
• 小規模な開発コミュニティ、あるいは単独スポンサードのプログラミング言語であれば同様の有償化リスクがなくはない
  • ある程度のコミュニティ規模と、民主的な意思決定プロセスがあればリスクは無視できるほど小さい
• 仮にこれが生じた場合、開発コミュニティが大きければ分裂してオープンソースの無償版が続くだろう
  • コミュニティが小さい場合は維持できなくなる可能性がある
  • 分裂した場合、商標権の関係などで、おなじかんばんを掲げ続けることはおそらく難しい。名前は変わるだろう
• セキュリティアップデートのような改変版について非GPLでは非公開・完全有料化のリスクが考えられる
• 開発を主導するスポンサー企業が傾くなどすると、開発が停滞するリスクがある
  • 一社独占のような体制だとこのリスクはやや大きい。もちろん、企業の財務状況が良ければ無視できる
• 小規模な開発コミュニティの場合、開発の中心人物に何かあると停滞が大きくなる可能性がある
  • ある程度の大きさに組織化できている開発コミュニティであれば小さな影響に抑えることができるかもしれない

現在の主要な言語ランタイムはいずれもオープンソースのライセンス体系をとっている。権利者がある日突然ライセンスを変更する！と言い出したとしても、過去のライセンス契約が無効になるわけではない。すでに自由に改変できる内容のライセンスでオープンソース化されている以上、最悪のケースでも現行バージョンからの派生物を作ることができる。

無償版ばかりが求められているわけでもなく、業務で利用されるサーバー上のJavaなどは、今も昔も有償サポートが用いられてきた。Oracleは今も昔も有償サポートを提供し続ける。Javaはサードパーティーからも提供される。これはリスクが分散されているポイントでもある。

ジェネリクスと配列

Javaのジェネリクスは一般に配列と混ぜてはいけないとされるが、混ぜて用いた場合に何が問題となるのか。

歴史的な問題

Javaが1995年に登場した当時、Javaに配列はあったがジェネリクスはなかった。

ジェネリクスを含む型システムの理論的な整備は、1990年代から2000年代にかけてのJavaのバージョンアップの時期に並行して行われていた。これは1995年当初のJavaになぜより良いジェネリクスを搭載した形でリリースされなかったのか？ということにひとつの答えを示すだろう。つまり、1995年当時にはジェネリクス（Java5に搭載されたような変性を含むもの）は未来の技術であって、まだ理論的に固まっていないものであった、というわけだ。

Java言語仕様にも記述されているが

Historically, wildcards are a direct descendant of the work by Atsushi Igarashi and Mirko Viroli. Readers interested in a more comprehensive discussion should refer to On Variance-Based Subtyping for Parametric Types by Atsushi Igarashi and Mirko Viroli, in the Proceedings of the 16th European Conference on Object Oriented Programming (ECOOP 2002). This work itself builds upon earlier work by Kresten Thorup and Mads Torgersen (Unifying Genericity, ECOOP 99), as well as a long tradition of work on declaration based variance that goes back to Pierre America's work on POOL (OOPSLA 89).

Javaのジェネリクスに現れるワイルドカード、そしてそれによって表現される変性については2002年のAtsushi Igarashi と Mirko Viroliの論文が元になっている。なお、Java5 がリリースされたのは2004年9月30日のことであった。

Javaの配列にはC言語の配列の影響が色濃く見える。配列を表す[]が型の側にも変数の側にもつけて宣言できるのもその影響の一端であろう。

String[] array1;
String array2[];

配列のString型はString型ではない。StringはStringを間接的に扱う。型を間接的に扱うのだから、ジェネリクス的である。C言語の配列が作られたとき、配列がジェネリクスであるという理解でもって設計されたわけではなかろう。しかし、現代から振り返ってみれば、配列は言語に組み込みの機能を限定したジェネリクスである、といえる。

配列はジェネリクスのようなもの

Javaでは参照型は親の型の変数に子の型を代入することはキャストなしに行うことができる。

Object o = new String("hoge");

これはリスコフの置換原則(Liskov, Barbara; Wing, Jeannette 1993年7月16日 Family Values: A Behavioral Notion of Subtyping)として知られる。

ごく端的に言えば、子は親の機能を代替できなくてはならない。代替できる前提において、子を親の型扱いすることができる。こうした変数の型に対して子や孫の型を代入できる関係を「共変性」(covariance)という。Javaの型システムの根幹をなす重要な概念だ。

しかし、型を間接的に用いるジェネリクスでは、変数を単純に共変とすることができない。

ArrayList<String> stringList = new ArrayList<String>();
ArrayList<Object> objectList = new ArrayList<Object>();
objectList = stringList; // コンパイルエラー

なぜか。

objectList = stringList; // 仮に出来たとする
objectList.add(new Object()); // stringList にObjectが格納される

ArrayList

Java Generics Hell アドベントカレンダー 24日目。

• 前回(22日目) イレイジャ

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

今回はJavaのジェネリクスでは型変数を用いてnew T()できないけど特に問題ないという話。

コンストラクタの形

コンストラクタは、その内部でthisが使えるしインスタンスフィールドへのアクセスもインスタンスメソッドへのアクセスも出来る。そこからするとインスタンススコープのメソッドのように見えるが、インスタンスに所属しているわけではない。

インスタンスメソッドを呼び出すにはインスタンスを指定するか、自分のインスタンスのメソッド呼び出しでthis.を省略できる、というシチュエーションでなくてはならない。逆に言えば通常のclassのnewはインスタンスなしで呼び出せるわけで、所属としてはclassのstaticに相当する。クラス名を指定する必要があるが、インスタンスを指定する必要はない、という独特のポジションである。

なので、継承を用いてinterfaceや親クラスによってコンストラクタの引数の形を規定することは出来ない。通常の継承の埒外にいるわけである。コンストラクタはリスコフの置換原則の範囲外で、親クラスのコンストラクタと同様に子クラスのコンストラクタが呼べる必要はない。

こうした前提を踏まえると、型変数のような任意の型に対して、統一的なnewをしたいというのはJavaの型システムの範疇で考えると無理であるし、無茶な要求と言える。Javaあたりの世代のプログラム言語ではコンストラクタの引数がどのようなものか、指定することが出来ないし、指定したければ継承の範囲を超えた別のプログラミングパラダイムが必要になる。

デフォルトコンストラクタ

さて、そんなわけで汎用にコンストラクタの形状を定めるというのは無理で、どうしてもやりたければ、インスタンスを生成するクラスというものを用意するという迂遠なやり方をする必要がある。迂遠というか面倒くさいわけだが、こうした生成を行うクラスを別途用意する（ビルダークラスとかファクトリークラスという呼ばれ方をする）ことで対処できるといえば出来る問題である。いわゆるボイラープレートというやつで、定型句がわさわさ出てきて煩わしいという話はあるにせよ、だ。

しかし、特定のシチュエーションでは決まったコンストラクタの型をしているという前提を置くことが、ある程度妥当性を持つことがある。デフォルトコンストラクタである。

インスタンスの生成を行うメソッド

デフォルトコンストラクタとは要するに引数なしのコンストラクタで、単なるデータを保持するようなクラスの場合、概ねデフォルトコンストラクタを持つという前提を想定してよいケースがある。例えばO/Rマッパーのようなケースで、所定の型のデフォルトコンストラクタでインスタンスを作ってリフレクションでデータを詰めて返したい、そのメソッドがジェネリクスで具象型を指定したい、というわけである。

public class ORMapper {
	public <T> T select(String query) { ... } // これでは生成できない
}

この場合、Javaでやるなら先に挙げたようにビルダークラスを使う必要がある。そして、Java8以降を前提とするならば、ビルダークラスはラムダ式ないしメソッド参照でよい。引数にjava.util.function.Supplier<T>を用いよう。

public class ORMapper {
	public <T> T select(Supplier<T> builder, String query) {
		T ret = builder.get();
		// (略) 詰め込む処理
		return ret;
	}
}

こうした場合、呼び出し側は

ORMapper mapper = new ORMapper();
Hoge hoge = mapper.select(Hoge::new, "select * from hoge");

といった具合である。今後のJavaのリリースで変数宣言時の型推論の導入が検討されている。それが導入されると次のように書けるようになるだろう。

ORMapper mapper = new ORMapper();
var hoge = mapper.select(Hoge::new, "select * from hoge");

C#の場合

さて、引き合いによく出されるC#では実行時にバインドされた型変数の型が引き回される。そして、new制約というデフォルトコンストラクタを持つことを型変数の制約とする特殊機能を使って（型クラスのような汎用機能ではないので過渡期の対処法だと思っておいた方が良いと思う）型変数でのnewを実現している。

https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/new-constraint

class ItemFactory<T> where T : new()
{
    public T GetNewItem()
    {
        return new T();
    }
}

ここでさっきのJavaのORMapperの例をC#にしてみると

public class ORMapper {
	public T Select<T>(String query) where T : new()
	{
		T ret = new T();
		// (略) 詰め込む処理
		return ret;
	}  
}

といった形になるだろう（筆者はC#は不案内なので誤りがあればご指摘願いたい）
この時、呼び出し側は

ORMapper mapper = new ORMapper();
var hoge = mapper.select<Hoge>("select * from hoge");

といった形になるだろう。
Java版（変数宣言時の型推論あり）と比較してみよう。

ORMapper mapper = new ORMapper();
var hoge = mapper.select(Hoge::new, "select * from hoge");

違いとしては、C#側ではメソッドスコープの型変数に対するバインドを明記する必要があり、代わりにnew制約を使うので引数にビルダークラスを取らなくて良い。Java側ではメソッドスコープの型変数は型推論で済ませる代わりにnew制約がないため引数にHoge::newを渡す必要がある。概ね、Hogeの位置が変わる程度で大差がない。

まとめ

• new制約が便利に見えるが、言うほど劇的な利便性が得られるわけでもない
• Javaでnew制約の代わりにTから実行時の型をとってリフレクションでnewInstance()しようというのは筋の悪いアプローチ
• 筋の悪いアプローチをしようとして出来ないからといってイレイジャに八つ当たりするのは見当違いではないか

イレイジャのせいにする言説もしばしば見かけるが、いささか見当違いと言えるだろう。何を問題視しているか冷静に検討したいところだ。

Java Generics Hell アドベントカレンダー 22日目。

• 前回(20日目) ブリッジメソッド

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

メソッドのオーバーロード

Javaのジェネリクスのイレイジャについて語るには、まずメソッドのオーバーロードについて語らねばなるまい。

メソッドのオーバーロードとは、同名で引数の型違いのメソッドのことである。

public class Hoge {
	public void foo() {}
	public void foo(String s) {}
}

Javaではなぜ同名のメソッドを宣言することが出来るのであろうか？コンパイラが、あるいはJavaのランタイムであるJavaVMが、メソッドを特定するときに

• 属するクラスの完全修飾名
• メソッド名
• 引数の型の並び

によってどのメソッドを呼ぶか特定しているのである。

これはリフレクションAPIにも現れていて、Methodを取得しようとした場合には

Class<Hoge> clazz = Hoge.class;
Method method = clazz.getMethod("foo", String.class);
System.out.println(method);

といったように

• 対象となるClassオブジェクトを取得してClass#getMethod()を呼ぶ
• 引数にはメソッド名と
• 引数の型の並びをClassの配列で渡す（可変長配列）

とする必要がある。

プログラム言語によってはオーバーロードを許していないものもある。オーバーロードを許さない言語では、メソッドを特定するのは楽で、

• 属するクラス
• メソッド名

だけが分かればよい。メソッドを呼び出すためにいちいち引数のクラスの羅列を用意する必要はなくなる。

イレイジャ

さて、オーバーロードについて振り返った。ジェネリクスのイレイジャを理解するにはオーバーロードについて振り返っておく必要があるのだ。Javaではメソッドを特定するために

• 属するクラスの完全修飾名
• メソッド名
• 引数の型の並び

が必要だと言ったが、この「引数の型の並び」はイレイジャである必要がある。

ここで、イレイジャの定義についてJava言語仕様より抜粋してみよう。

4.6 型のイレイジャ
型のイレイジャ（type erasuer:型消去）とは，型（パラメータ化型や型変数を含む）から型（パラメータ化型や型変数を含まない）への対応付けである。型Tのイレイジャは|T|と表記される。イレイジャの対応付けは以下のように定義される。
・パラメータ化型(§4.5) Gのイレイジャは|G|である。
・ネストされた型T.Cのイレイジャは|T|.Cである。
・配列型Tのイレイジャは|T|である。
・型変数(§4.4)のイレイジャは，その最も左端の境界におけるイレイジャである。
・その他の型すべてのイレイジャは，その型自身である。
メソッド・シグネチャsのイレイジャは，sと同じ名前，およびs中で指定されたすべての形式的パラメータ型のイレイジャからなるシグネチャとなる。

「パラメータ化型」という単語が出てくるが本稿シリーズでは「パラメタライズドタイプ」と呼んでいる。つまり、List<String>のような型のことである。なので、先程のメソッドを特定するための条件は正確には

• 属するクラスの完全修飾名
• メソッド名
• 引数の型のイレイジャの並び

ということになる。

このことによる直接的なデメリットは、引数のイレイジャが同じになるメソッドのオーバーロードが許されないということである。

これがもし、メソッドを特定するために

• 属するクラスの完全修飾名
• メソッド名
• 引数の型(パラメタライズドタイプのパラメータも含む)の並び

となっていれば、引数の型のさらにパラメータの違いによってメソッドの区別が出来ることになる。もちろん、そのためにコンパイラやランタイムはいちいちメソッドを特定するためにそれだけの情報を参照する必要が生じるということでもある。

歴史的な経緯を言えば、Javaは1.4から5の間でジェネリクスが追加されたのであった。この時、メソッドを特定する仕組みを旧来のものと互換をとった。それがイレイジャ方式というわけである。

イレイジャ方式のメリットは、互換性のキープもあるが、リフレクションなどで扱う際に煩雑になりすぎない点がある。これは実行時の型エラーと表裏一体のものではあるが、JavaVM上でより拡張された型システムを構築する場合（つまりそのような拡張された言語を作るような場合）にやりやすいということでもある。

よくある誤解

Javaはメソッドの特定の際にイレイジャを用いて特定するということは前節で述べたが、Javaのclassファイルに「イレイジャしか格納されていない」わけではない。

これは、引数にList<String>を取るメソッドがあったとして

public class Hoge {
  public void foo(List<String> list) {}
}

これをコンパイルしてHoge.classファイルを作る。

次に、このHoge.classファイルだけをもってきてクラスパスを通し、別のクラスからこのメソッドfooを呼び出す。

public class Main {
  public static void main(String[] args) {
    Hoge hoge = new Hoge();
    List<String> list = new ArrayList<String>();
    hoge.foo(list);  // OK

    List<Integer> list2 = new ArrayList<Integer>();
    hoge.foo(list2);  // NG
  }
}

この時、hoge.foo(list);はコンパイルが通るとして、パラメタライズドタイプのパラメータが異なるhoge.foo(list2);はコンパイルエラーとなる。classファイルにfooの引数がList<String>のイレイジャ|List|だけが残されているのだとしたら、引数に誤ってList<Integer>を渡そうとした場合にコンパイルエラーに出来ないはずである。

しかし、現実にはコンパイルエラーになる。classファイルにはしっかりとパラメタライズドタイプのパラメータは保持されているし、リフレクションでこのパラメータを読み出すことも出来る。

Java Generics Hell アドベントカレンダー 20日目。

• 前回(19日目) 内部クラスと型変数のスコープ

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

共変戻り値

Java5以降ではメソッドをオーバーライドするときに、戻り値をより具体的な型としてオーバーライドすることが許されている。

public interface Parent {
    Number getValue();
}

このjava.lang.Number型を返すgetValue()メソッドをChild型でオーバーライドするときにNumberの子であるInteger型にすることができる。

public class Child implements Parent {
    public Integer getValue() {
        return 0;
    }
}

これが共変戻り値だ。

ジェネリクスを用いている場合に、継承でバインドすると同様の共変戻り値となることがある。

public interface Parent<T> {
    T getValue();
}

public class Child implements Parent<Integer> {
    public Integer getValue() {
        return 0;
    }
}

bridge メソッド

これらのケースで、Child型のclassファイルを覗くと面白いものが見える。

>javap Child.class
Compiled from "Child.java"
public class Child implements Parent {
public Child();
public java.lang.Integer getValue();
public java.lang.Object getValue();
}

getValue()がふたつあるのが分かるだろうか。Eclipseのclassファイルビューアだと以下のように見える。

// Method descriptor #24 ()Ljava/lang/Object;
// Stack: 1, Locals: 1
public bridge synthetic java.lang.Object getValue();
0 aload_0 [this]
1 invokevirtual Child.getValue() : java.lang.Integer [25]
4 areturn
Line numbers:
[pc: 0, line: 1]

bridge syntheticと記載があるのが分かるだろうか。これが今日のテーマ、ブリッジメソッド(bridge method)だ。

引数のブリッジ

さて、共変戻り値の例を挙げたが、型変数を引数にとる場合でも同様の事例が発生する。

public interface Parent<T> {
	void xxx(T t);
}

public class Child implements Parent<String> {
	@Override
	public void xxx(String t) {
	}
}

ここで型変数Tは境界がないので、Parentのメソッドxxxの実際のシグニチャはxxx(Object)となっている。

Childでは型変数を継承でバインドしてStringとしているので、Parentのメソッドxxx(Object)をオーバーライドしてxxx(String)としてしまっている。

Javaでは呼び出すメソッドを決めるときに「メソッド名」と「引数の型」が必要だった（より正確には引数の型のイレイジャとなる。拙稿贖罪のイレイジャを参照されたし）。「メソッド名」が同一で「引数の型」が異なる場合、オーバーロードとなることはJavaの初歩で習うことだ。しかし、ここではxxx(Object)とxxx(String)となっている。

そこで、こうしたケースで、もとのメソッドシグネチャであるxxx(Object)を「ブリッジメソッド」として、xxx(String)を呼び出す実装をコンパイラが作り出す。

リフレクション

こうしたブリッジメソッドはリフレクションでメソッド一覧を取得したようなときにも現れる。

そこでjava.lang.reflect.Methodクラスにはブリッジメソッドであることを判別するためのisBridge()が用意されている。

また、似たような話題としてisSynthetic()というメソッドも用意されている。これは合成(synthetic)されたメソッドにつくフラグで、このブリッジメソッドの他にもコンパイラによって生成されたメソッドに立てられる。

Java言語仕様第3版 13.1 Javaバイナリの形式 (299ページ)から抜粋すると

・コンパイラによって導入された，ソースコード中に対応する構造のない任意の構造は，デフオルトのコン
ストラクタとクラス初期化メソッドを除いてすべて，合成（synthetic）されたものである旨記録されなけ
ればならない。

と書かれている。先のclassファイルビューアにあったbridge syntheticの記載の意味はコンパイラによって作られたブリッジメソッドというフラグだったというわけだ。

ブリッジメソッドの衝突

ところでブリッジメソッドが衝突するとどうなるのか？

public interface Parent<T> {
	void xxx(T t);
	void xxx(String s);
}

class Child implements Parent<String> {
	@Override
	public void xxx(String t) {
	}
}

この場合はこのままコンパイルに成功する。ちょっと面白い現象だ。

まとめ

• 共変な戻り値や、型変数を引数にして継承でバインドした場合などで、オーバーライドにも関わらずメソッドシグネチャが異なるケースが生じる
• こうしたケースでは親クラスのシグネチャと同等な「ブリッジメソッド」がコンパイラによって作られ、オーバーライドした具象型のメソッドへブリッジする
• ブリッジメソッドであるかどうかはjava.lang.reflect.MethodクラスのisBridge()メソッドで判別できる

Java Generics Hell アドベントカレンダー 19日目。

• 前回(18日目) ジェネリックな例外

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

Javaでは1ファイルにトップレベルのpublicなclassはひとつしか置けないが、入れ子になったクラスなどを用意することができる。種類がいくつかあるので後に整理するが、内部クラスの場合、外側のインスタンススコープの型変数が内部クラスの内側でも有効となる。

今回はそのあたりを整理してみよう。Javaのクラス宣言の種類については拙稿 Javaのクラス宣言5種+αで以前に取り上げているので参考にされたい。

static

内部クラスの話の前に、そもそも論としてクラスのインスタンススコープの型変数は、staticなメソッドや、フィールドでは用いることは出来ない。なぜなら、インスタンスをスコープとしているからだ。（トートロジー的な）

なお、コンストラクタはインスタンスメソッド扱いで型変数を使える。その他、static初期化ブロックはstatic扱いなので型変数を使えない。インスタンス初期化ブロックであればインスタンスの型変数を用いることができる。

トップレベルの同居したクラス

Javaではpublic/protectedなトップレベルのclassは .java ファイルにひとつしか置けないが、パッケージプライベートなclassは複数置くことができる。なお、privateなトップレベルクラスはそもそも作れない。例えばTopLevel.javaというファイルに以下の内容を記述するとコンパイルすることが出来、TopLevel.class と TopLevel2.class が作られる。

public class TopLevel<T> {
}
class TopLevel2 {
}

上記例のTopLevel2はトップレベルなので、当然ながら相互に型変数のスコープは独立している。つまり、考慮しなくて良い。

ネストしたクラス

ネストしたクラス (Nested class) は、class 内部に

• static class を宣言したもの
• interface を宣言したもの
• enum を宣言したもの

である。

これらは、名前が「外側のクラス名. ネストしたクラス名」で扱われるが、基本的にトップレベルクラスと同等である。

public class TopLevel<T> {
	static class Nest1 {
	}
	interface Nest2 {
	}
	enum Nest3 {
	}
}

違いといえば、アクセスレベルをパッケージプライベートやprivateにすることができる。private宣言すると内部的にclassを作るものの、外部に露出させないことが可能だ。

これらもトップレベルクラスと同等で、外側のTopLevelの型変数Tをこれらネストしたクラス内で用いることは出来ない。

内部クラス

内部クラス(Inner class)は外部クラスのインスタンスに紐付く。そのため、外側のクラスのインスタンスの型変数を用いることができる。

public class TopLevel<T> {
	class Inner {
		T t;
		void hoge(T t) {}
	}
}

しかし、内部クラスといえども、内部クラスのstaticメソッドではTopLevelのTを扱うことは出来ない。

なお、内部クラスが3段以上になった場合、3段目では、1番外側のクラスで宣言された型変数、2段目で宣言された型変数の両方を用いることができる。実用上はそういうケースはなかなか発生しないとは思うが。

ローカル内部クラス

ローカル内部クラス(Local inner class)はメソッドやコンストラクタなどのブロック内で宣言されるクラス。このクラスはブロックがスコープとなるのだが、そのブロックで有効な外側の型変数はこのクラス内でも用いることができる。

public class TopLevel<T> {
	/** staticメソッド */
	static <S> void staticMethod() {
		class LocalInnerClass {
			S s; // メソッドスコープのSは使える
			// T t; インスタンススコープのTはNG
		}
	}
	/** インスタンスメソッド */
	<I> void instanceMethod() {
		class LocalInnerClass {
			I i; // メソッドスコープのIが使える
			T t; // インスタンススコープのTも使える
		}
	}
}

上記例では、staticメソッドではメソッドスコープのSは使えるが、インスタンススコープのTは使えない。対して、インスタンスメソッドでは両方を用いることができる。

無名クラス

無名クラス（匿名クラスとも呼ばれる）(Anonymous class)は主に抽象クラスやinterfaceなどに対して名前を付けずにその場で実装を書くもの。
これもローカル内部クラス同様にそのブロックで有効な外側の型変数はこのクラス内でも用いることができる。

public class TopLevel<T> {
	/** staticメソッド */
	static <S> void staticMethod() {
		Runnable run = new Runnable(){
			S s; // メソッドスコープのSは使える
			// T t; インスタンススコープのTはNG
			@Override
			public void run() {
				S s2;
			}
		};
	}
	/** インスタンスメソッド */
	<I> void instanceMethod() {
		Runnable run = new Runnable(){
			I i; // メソッドスコープのIが使える
			T t; // インスタンススコープのTも使える
			@Override
			public void run() {
				I i2;
				T t2;
			}
		};
	}
}

余談

ローカル内部クラスや無名クラスの中に内部クラスを作ると、外側のブロックで有効なメソッドスコープの型変数を内部クラスで用いることができる。

public class TopLevel<T> {
	/** staticメソッド */
	static <S> void staticMethod() {
		/** ローカル内部クラス */
		class LocalInnerClass {
			/** 内部クラス */
			class InnerClass {
				S s;
			}
		}
	}
}

内部クラスは、外側のクラスで利用可能な型変数は使える、ぐらいに理解しておくと良いだろう。え？こんな使い方することはないって？

Java Generics Hell アドベントカレンダー 18日目。

• 前回(16日目) 型変数のバインド

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

throws E

Java のジェネリクスの型変数は例外のthrows宣言でも用いることができる。型変数の宣言時にthrow可能な型であることを型変数の境界で示す必要がある。

public <E extends Exception> void hoge() throws E {}

上記はメソッドスコープの型変数 E を extends Exception としてみた。メソッドスコープの型変数だとthrowsに型変数を用いる意味があまりないが、型システムの挙動を見る分にはコード量が少なくて済むので都合が良い。

バインドの仕方でthrowされうる例外が変わる、例外が変わるのでcatchするべき例外も変わる。

// IOExceptionをバインド
try {
	this.<IOException>hoge();
} catch (IOException e) {
	// 略
}
// SQLExceptionをバインド
try {
	this.<SQLException>hoge();
} catch (SQLException e) {
	// 略
}
// RuntimeExceptionをバインド
// catch不要
this.<RuntimeException>hoge();

面白いのはRuntimeExceptionをバインドした場合は、catch不要となることだ。

AutoCloseableの例

ここで、java.lang.AutoCloseableを見てみよう。通常、メソッドのthrowsは具象型が用いられる。

public interface AutoCloseable {
    void close() throws Exception;
}

例えばjava.io.ByteArrayInputStreamでは

public class ByteArrayInputStream extends InputStream {
    // 略

    public void close() throws IOException {
    }
}

となっていて、ByteArrayInputStreamの具象型を扱っていてもclose()を呼ぶ際にIOExceptionが発生する扱いとなる。

byte[] buf = new byte[100];
try (ByteArrayInputStream bais = new ByteArrayInputStream(buf)) {
	// 略
} catch (IOException e) {
	// close() が throws IOException のため
}

throws Exceptionではなくthrows IOExceptionなのは、例外がメソッドからの出力であるため、より狭い、より具体的な型に絞っても良いからである。このあたりはジェネリクス以前からのJavaの型システムの機能性だが、ジェネリクスのワイルドカードの話にも似ている。

というか、オーバーライドしてthrowsなくしておけばよかったじゃないか、という話もあるんだが、APIの歴史的な後の祭り。Java 1.0 のときに thrwos IOExceptionとしてしまったので、これをなくすとthrowされないIOEexceptionをcatchするコードがコンパイルエラーになってしまうので残されているのである。Javaは到達不能コードをコンパイルエラーにする方針なのでしょうがない。

話がそれた。

ここで言っておきたいのは、AutoCloseable型変数に一度代入してしまえば、そのclose()はthrows Exceptionだということだ。

byte[] buf = new byte[100];
ByteArrayInputStream bais = new ByteArrayInputStream(buf);
try (AutoCloseable ac = bais) {
	// 略
} catch (Exception e) {
	// IOException ではなく Exception になる
}

この点がジェネリクスなしでの不都合ということになる。

例外をインスタンス型変数にした場合

ではここにAutoCloseableとの対比としてinterface Foo を以下のように定めてみよう。

public interface Foo<E extends Exception> {
	void foo() throws E;
}

これをimplementsするclassは以下のようになる。

public class Bar implements Foo<IOException> {
	@Override
	public void foo() throws IOException {}
}

オーバーライドするにあたって throws IOException となった。
これでパラメタライズドタイプを用いて以下のように書ける。

Bar bar = new Bar();
Foo<IOException> foo = bar;

try {
    foo.foo();
} catch (IOException e) {
    // IOExceptionで済む
}

とはいえ、Fooがパラメタライズドタイプになって鬱陶しい。

なお、Foo<RuntimeException>であればcatch不要となる。

まとめ

例外のthrows宣言に型変数を用いることができるが、正直、あんまり活用できるポイントはない。