Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから

―きしださんの過去の登壇資料を拝見すると、2005年～2010年のJavaが「停滞期」と記載されていました。なぜでしょうか？

きしだ　この時期のJavaの停滞には、Sun Microsystemsの経営状況がもろに影響していると思います。当時のSun Microsystemsは経営難に陥っていました。

Sun Microsystemsは長期にわたりJavaをめぐる裁判をMicrosoftと行っていて、2004年にMicrosoftから19億ドルの和解金を受け取ったものの、経営状況は好転しない。その影響か、2006年に出たJava SE 6ではほとんど目立った新機能の追加がありませんでした。さらに2008年に発生したリーマンショックが、状況の悪化に追い打ちをかけました。その後、2010年にOracleによってSun Microsystemsが買収されたんです。

きしださんの視点による、Javaの歴史概観。ゼロ年代後半を「停滞期」と表現している。

―OracleによるSun買収以降、リリースや機能追加の流れは変わりましたか？

きしだ　まず、買収の後にすぐJava SE7が出たことが大きいです。Java SE6がリリースされてからJava SE7が出るまで5年がかかっているんですが、この期間は先ほど話した経営難が影響しているのか、新機能の開発がほとんど進んでいなかったように感じます。開発とリリースのサイクルが、なかなかうまく回っていなかった5年だったという印象です。

ですが、Oracleによる買収以降、流れが変わりました。例えば、もともとはラムダ式やモジュールの機能がJava SE7に入る予定で、その実装後にJava SE7がリリースされる予定だったんです。しかしOracleは「実装できている機能をまずはきちんとリリースする」ということを優先して、ラムダ式やモジュールの導入をJava SE8まで見送る決断をし、Java SE7を早急にリリースしました。運営方針の違いが見えて面白いですよね。モジュールは結局Java SE 9まで持ち越されましたけど。

その後、リリースサイクルも半年のスパンに変化し、Javaのリリースがきちんと回る状態になってきました。

―いわゆる、停滞期だった頃のJavaと、リリースサイクルが早くなった現在のJavaとでは、どのような点に違いが出ていると思いますか？

きしだ　大きな機能の開発が着実に進むようになっていますが、面白いのは、細かい変更もちゃんと入るようになったことです。例えばJavaでは、要素数が3の配列に対して要素数の5番目を選ぶとArrayIndexOutOfBoundsExceptionが発生しますよね。

以前はこの例外が発生した場合には、java.lang.ArrayIndexOutOfBoundsException: 5のように表示されるだけで、あまり参考になるようなエラー出力ではなかったです。ですがJava 11からは「配列の要素は3つなのに5番目を選んだ」という趣旨の、より原因が把握しやすいエラー出力に変わったんです。

今までは、そういった細かい変更があまり入らなかったんですよ。例外メッセージの改善なんて、いったい何年放置されてたんだという。おそらく、その変更を入れてもリリースされるのは3年後とか5年後かもしれないという状態だと、中にいるエンジニアたちも小さい修正を入れるモチベーションが湧かなかったのでは、と。

でも、今のリリースサイクルならば、改修をして取り込まれたら半年後には必ずリリースされる。だからこそ、Javaのメンテナンスをしている方々のモチベーションそのものが向上している印象を受けます。

Javaならば「この書き方がベスト」と信じてコードを書ける

―これまで、メインで使う言語を他のものにする選択肢もあったかと思います。ですが、きしださんがJavaを使い続けてきたのってどうしてですか？

きしだ　いえいえ、「他の言語をメインで使おうかな」と思うこともありますよ（笑）。

―そうなんですか。では、なぜJavaを使い続けてきたのでしょうか？

きしだ　他の言語を使うことで得られるメリットと、Javaによって実現できることを天秤にかけたときに「これ、Javaで書けばいいじゃん」と最終的に思ってしまうんですよね。結局、仕様を全て分かっている言語を使う方が、一番良い書き方ができるので。僕にとってはその言語がJavaです。

基本的に、僕が書いたコードはJavaとしては最適なコードになっているはずなんです。ある処理を実現するために何通りもの方法があるうち、「この書き方がベストだ」と信じて書ける。どうしてその書き方を選んだのかをきちんと説明できますし、迷ったときもどこを調べればいいのか分かる。

例えば、APIの裏側の処理はこうなっているから、こっちよりもこの書き方がいいとか、文字列の連結はこのバージョンからこうコンパイルされているからこれを使った方がいいとか、この機能は歴史的経緯で残っているだけで使わない方がいいとか。

―「信じて書ける」という言葉に、積み上げてきた知識の深さが伺えますね。例えば、初心者の方がやってしまいがちな「Javaの良くない書き方」の例はありますか？

きしだ　良くないというよりは、“より良い書き方”があるという感じですね。例えば、JDK9以降では基本的にArrays.asListよりもList.ofを使うほうがいい、などですかね。Arrays.asListが返すListは配列のラッパなのでサイズは固定でも要素の変更が可能なんですが、List.ofが返すListはきちんとimmutableになっていて要素の変更ができないようになっています。

それから、例えば複数のstreamで共通的に使うために、次のコード1のようにFunctionalInterfaceのフィールドを定義して、コード2のように使う方がいますよね。

// コード1
final Function<String, Price> CONVERT_STRING_TO_PRICE = 
  str -> str.substring(0, str.length() - 1).transfer(Price::of);

// コード2
return inputs.stream()
  .map(CONVERT_STRING_TO_PRICE)
  .collect(toList());

でもこれは、コード3のように普通にメソッドとして定義し、コード4のようにメソッド参照を使う方がいいです。

// コード3
Price stringToPrice(String str) {
  return str.substring(0, str.length() - 1).transfer(Price::of);
}

// コード4
return inputs.stream()
  .map(Converters::stringToPrice)
  .collect(toList());

なぜならば、ラムダ式を書くと内部では普通のメソッドが作られてメソッド参照が割り当てられているからです。つまり、メソッド定義を省略したつもりでも、結局はメソッドが作られているんですよ。

ならば、直接メソッドを作った方が処理と記術の差異がない。それに、FunctionalInterfaceは普通のメソッドよりも読むのが難しいですから、それよりは誰にとっても読みやすい書き方の方がいい。こういった「Javaをどう書くのがベストなのか」のパターンは以下にまとめています。

きっとまた、Javaが一番フィットする分野が現れる

―今後、Javaという技術は今後どのように使われていくと思いますか？

きしだ　前提として、Javaは次世代COBOLだと僕は思っているんです。COBOLが60年近く使われているように、Javaもこれから何十年も使われ続けるだろうと。多くの企業が過去にJavaで開発してきた業務システムを、他の言語にリプレイスする必然性は基本的にないですよね。そうするとJavaは今後も使い続けられるし、使い続けられるようにしていかないといけない。だからこそ、長期的な視野に立ってJavaを使い続けられるんです。

現在、Javaのリリースサイクルが変わって、新機能の追加も非常に活発になっています。そして、最新のハードウェア・ソフトウェアにフィットさせるような改善もずっと続けていますから、その努力を続けていれば、どこかでまたJavaがもっとも適した領域が現れて、大きな波が来るだろうと僕は思っています。

プログラミング言語の流行り廃りはありますが、90年代のCや2000年代のJavaのように、なにか1つの言語が世界を支配することは、今後あり得ないと考えています。

―最後に、きしださんの思う「Javaが持つ良さ」について教えてください。

きしだ　Javaは全部ができる言語だということですね。デスクトップアプリも、サーバーサイドも、スマホアプリも、業務系のアプリもサービス系のアプリもできる。機械学習は、まだそんなに向いていないですけど、きっと将来的にはもっと楽にできるようになる。Javaを習得することで、さまざまな領域に手を出せるのが利点だと思ってます。

それから先ほども話に出たように、Javaは新しい要素技術にフィットしていこうとする努力を続けていますから、その流れに追従していくと自分自身が新しい技術を勉強するモチベーションになります。言語だけではなく、ライブラリやフレームワーク、実行系も全部まとめてJavaなんです。守備範囲の広さが、Javaの一番いいところですよね。

取材・執筆：中薗昴