JDKのバージョンアップポリシーについて

長いだけでオチは無いよ。

「Java6がサポート切れた」だの「秋にはJava8が出る」だのとJavaのバージョンアップキャンペーンっぽい話題をちらほら聞きますよね。実際、保守しているシステムも、やれハードウェアの老朽化だ、OSやミドルウェアの保守切れだ、とかいう理由で否応なしにJVMのバージョンアップをするハメになりますよね。でもコンパイラ（JDK）のバージョンアップってどうしてるんですかね？

JVMはそれを必要とするミドルウェア（大抵はAPサーバですわな）がサポートしてないって大義名分があるので、Java5だJava6だと定期的にバージョンアップしてくんだけど、その上で動いているシステム（まあ業務アプリだわな）のコンパイラ（JDK）まで気にしてるって話は意外なほど聞かないのよね。

んで、どうしてるかというと、何もしない。いわゆるSI業界では、ソフトウェアは「やわらかいモノ」ではなく「モロいモノ」という扱いなので「寝た子は起こすな」が鉄則なので、要らんことはしない。したがって、JDK1.4が主流だった時に作成したシステムは2013年になった今でもJDK1.4でコンパイルしているのが普通...なんだと思うのデスよ。
え？そんな古いJDKどっから手に入れるかって？抜け目の無いプロジェクトは、保守に必要な環境をインストーラごと保管しているので、そんな心配はご無用さ。:-)

システムを構築した業態・業界にもよると思うんですが、業務システムって想像以上に長生きで、2000年あたりに新規構築したシステムが今でも現役なんて珍しくないですよね（と誰とは無く。

「JDKは据え置き」が果たしていいのか？というと悪いとも思うし、良いとも思う。つまるところ、そのプロジェクトなり会社なりのバージョンアップポリシー如何なんだけど、実際は前述の通り「何かあったら怖いから現状のままにしてる」が多数派なんじゃなかろうかと。なんで「ウチはこれこれ、こうゆう理由で、こんな対応してるよ」って事例があったら、それによろこんで倣うと思うんですよね。それがある程度の権威がある事例だったらなおさら。:-P

そうは言っても、選択肢は多くは無くて、やる事と言ったら

JDKのバージョンは塩漬けのまま変えない
JDKもバージョンアップするJVMと同じバージョンにあわせる

くらいかと。後者（JDKもバージョンアップ）を選ぶ理由のわかりやすい例は「JDKだってサポートプラットフォームがあるんだぞ」ってヤツ。今でもWindowsXPで開発してるところはあるけど、だいたいWindows7使ってるところもあるよね。で、仮にJDK1.4を使うとして、それがWindows7をサポートしてるか？っていったら、そんなワケないですよね。

正直、JDKのサポートプラットフォームなんて「細けぇこたぁどうでも良いんだ」と思うのだけど寝た子を起こすな哲学は長いものに巻かれろ哲学と互換性があるので、何かあっても文句言えるところを確保するってのも立派な理由のひとつですわな。

じゃあ、JDKもいっしょにバージョンアップするとした場合、どんなパターンが考えられるか。

JDKだけバージョンアップしてコンパイルする

大抵、これでしょうね。多少、警告が出ると思うけど見なかったことにして、ほとんど何もしないで完了する。運が悪いと、次の理由でコードを修正することになるけどね。

変数名とかが新しいJDKで採用された予約語と被った
- assertが被るって事はそうそう無いけど、enumはありそう。:-)
JDKのAPIを独自拡張してるクラスが、JDK側のAPIの追加・非推奨化の影響を受けた
- 継承したり委譲してたりしてたJDKのAPIが増えた・減った場合ですね。これはフレームワークとかユーティリティを自作してると直面しそうですね。

JDKのバージョンアップに伴い、ソースコードもそのJDKの特徴にあわせて修正する

たとえばJDK1.4からJDK5以上にしたから、ついでにソースコードにも手を加えて、拡張forやオートボクシング、ジェネリクスといった特徴を取り込もうってヤツです。普通の発想だったらまずやりませんよね、こんなことｗ

個人的には、この手（ミドルウェアの更新みたいな）バージョンアップは４〜５年に１回の割合でしか起きないので、これくらいの無難な変更を全体に行うことで保守要員の育成にもなるんじゃないかなって思うんですよね。なんですかね、伊勢神宮方式とでも言いますかね。
ただ現実問題、

そんな広範囲に手を加えるためのコストが捻出できない
無難な修正といってもデグレードを起こす可能性はある

などの理由で、これが採用されることはないだろうなと思ってます（そんな話を聞いた試しもない。:-P

そんわけで、JDKは据え置き／運が良くてJVMと同じバージョンのJDKを使うけどソースコードは必要最低限しか弄らないのどっちかだろなと。ただ後者（JDKもバージョンアップ）を選択した場合、その後の保守でソースコードに手を加えるときはどうすんだ？って疑問が残るのですよ。

つまり「元はJDK1.4で作ったソースコードだけど、今はJDK7でコンパイルしてる」なーんて状況で、何かしらの仕様変更を行うとき、そのソースコードはJDK7の特徴を存分に使っていいのかどうかって事ですわ。放っておくと、eclipseさんやNetBeansさんといったIDEが気を利かせて、最新のJDKの特徴を駆使したテンプレートを展開したり、何古くさいコード書いてんだって警告してくれるので、否応なしに新しいコードになってきますよね。で、古い書き方のコードと新しい書き方のコードがパッチワークみたいに混在しちゃうわけだ。

「それでいいのか！？」って思うけど、それもプロジェクト事のポリシーに寄るんだよね。当然、パッチワークになるのを嫌えば新しい書き方禁止！で、カビが生えたプロジェクト固有のコーディングルールを守るわけだ。これって特に若手にとって不幸な事だと思うのよね。だって書籍だの研修だので覚えるJavaはいわゆる近代のJavaだと思うんだ、なのに仕事で書くのは習ったことも無い古典Javaなーんて話が笑い話じゃ無く起きてる。

Java5、Java6、Java7でもって今度はJava8でそれなりにJavaも便利な書き方ができるようになってるんだけど、すぐに新しい特徴を取り込める状況にあるかというと、そうでも無いどころか、取り込むのを禁止したいと思う状況だったりするので、悩みは尽きないのですよ（でオチも無いｗ

ps.
ちなみに、JDK1.2からJDK7.0までの間にJDKの互換性がらみで困ったことは、この２つくらいしかないんですよ。

enumが予約語になった（JDK5.0から）
JDK1.4までのBigDecimal.toString()がJDK5.0からBigDecimal.toPlainString()になった
- 他にもJDBCまわりでAPIの増減はあったけど、それで困るケースってそうなかった

それ以外については、JDK1.2でコンパイルしたクラスファイルであろうと元気に最新のJVMで動くので、Javaの上位互換性はスゴいなって正直思う（それ故にBigDecimalの件はイラっと来たけど）。

ふむふむ。