JetBrainsがKotlin 1.0をリリース

ベータ版からわずか数ヶ月後，JetBrainは，Androidに対応する新たなJVMベース言語であるKotlinの初となる安定版リリースを発表した。同社によれば，この言語は，実用性と相互運用性を重視した設計判断という開発方針の下で，“優れたツール”となることを目指したものだ。Javaならばライブラリや外部ツールを使わなくてはならないような問題の多くに対処すると同時に，Javaからの円滑で段階的な移行も実現している。

2010年にKotlinの着想を得たJetBrainだが，その開発を決めたのは，元々は自分たちの製品開発の生産性を向上する手段としてだった(Kotlinは現在，IntelliJ IDEAと並んでJetBrainsの製品に使用されている)。その後，多くのユーザが同じような問題に直面しているのではないかと考えた同社は，Kotlinをオープンソース化して，開発参加とコントリビューションを広く求めることにした。ターゲットがJava 1.6であることも相まって，間もなくKotlinはAndroid開発者の間で人気となり，他のJavaバージョンや言語が持つ新機能を次々と追加していった。その人気の程は，JRebel for Androidなどの新しいAndroid用開発ツールがKotlinサポートを備えていることからも伺い知れる。

Android開発の領域においてKotlinがJavaに対して持つアドバンテージは，AndroidのOpenJDK移行が完了することで削がれるかも知れない。しかしながら，開発者が恩恵を受けることのできる分野は他にもたくさんある。例えば次のような分野だ。

• Getter/Settrerボイラプレート: Java言語でプロパティを操作するコードを書く場合，IDEによるコード生成やProject Lombokなどのバイトコード操作，あるいはもっと単純に，内部フィールドを公開して(カプセル化の原則に反するが)実現するのが一般的だ。Kotlinではデータクラスを作ることで，すべてのプロパティに対するGetterとSetterがデフォルトで用意される。
• toString, hashCode, equals: Javaはこの３つのメソッドのデフォルト実装を提供しているが，これらが役に立つことはほとんどなく，通常は開発者がオーバーライドして独自の実装を用意しなければならない。ほとんどの場合，必要な実装はApache Commons LangやGoogle Guavaなどのライブラリが用意しているような，ごく単純なものだ。Kotlinのデータクラスではクラスのフィールドに基づいて，これら３つのメソッドのデフォルト実装が提供される。大部分の開発者にはこれで十分で，メソッドをオーバーライドする必要はない。また，Kotlinの‘==‘演算子は参照の比較ではなく，equalメソッドとして動作する。
• オブジェクトの部分構築: オブジェクトを構築する場合，パラメータを一部のみ指定して，残りはデフォルト値をそのまま使用する必要のあることは少なくない。一般的にこれはビルダパターンを使って実現されるが，それにはターゲットクラスと合わせたビルダクラスの作成も必要になる。Kotlinは名前付き引数のサポートによってこの問題を解決する。
• Nullチェック: null回避はJava開発者にとっていつも頭痛の種だ。一般的にはIDEのインスペクション(常にnullになる値の検出)や複数形クラス(Objects.requireNotNull())によるアサーション，@NotNullや@NonNullなどのアノテーションによる暗黙のバリデーション，GoogleのOptional，最近であればJava 8のOptionalが使用される。Kotlinではnullの概念が言語そのものに移行されているため，変数自体がnull設定可能かどうかを，コンパイル時に認識できるようになった。

val x: String? = "Hi" // null設定可能な文字列としてxを宣言
x.length // xがnull設定可能であるためコンパイル不可，nullチェックを先に行なう必要がある

if (x != null) {
    x.length // コンパイル可能，Kotlinはここでxがnullでないことを認識している
}

val y: String = null // コンパイル不可，yがnull設定可能と宣言されていないため

• String構築: JavaでStringを構築するには，結合演算子("a " + variable + " b")，もっと読みやすくするためにString.format()メソッド(String.format("a %s b", variable))，パフォーマンスが問題ならばStringBuilderあるいはStringBuffer(new StringBuilder().append("a ").append(variable).append(" b").build())が使用される。KotlinはRubyなどの言語にあるような文字列補完をサポートしているので，”a ${variable} b”と簡単に記述できる。
• Java 8以前の環境でのラムダ: ラムダ式は最新バージョンのJavaでのみサポートされているが，現在でも広く利用されているそれ以前のバージョンではサポートされていない。古いバージョンでラムダを使用するためには，Retrolambdaなどのツールを利用しなければならなかった。Kotlinはラムダのサポートを提供するが，Java 6をターゲットとしているので，古い環境でもこの機能の利用が可能になる。

その他にも，日常的な問題のいくつかが，Kotlinを使用することによって簡単に対処できるようになる。しかしながら，多数のメリットがある一方で，新しい言語の採用には独特のリスクや課題もある。また，既存プロジェクトでKotlinを採用する場合，JavaとKotlinのコードがかなり長期間にわたって共存することにもなる。JetBrainsでは，可能な限りの相互運用性を持たせると同時に，Java-to-Kotlinコンバータを提供することで，この問題への対処を図っている。

一方で，ユーザが新たなツールに対して安全な投資を行なうには，長期間にわたるサポートも必要になる。JetBrainsでは，非常に多くのリソース(20人以上のフルタイム開発者)をアサインすることと，コミュニティのコントリビューションを通じた標準化プロセスを確約することで，Kotlinに対する同社のコミットメントを示している。さらに同社は，すべての新バージョンが後方互換性を備えるとも約束している。こうした原則は，リファレンスプラットフォームのオープンソース化(OpenJDK)，コミュニティ主体の標準化プロセス(JCP)，同じくすべての新バージョンの後方互換性の約束といった面から，Javaそれ自体のガバナンスを想起させる。

数を増やし続けている(これまでに50以上)JVM言語の中で，Kotlinが抜きん出た存在になり得るかどうかはまだ分からない。しかしながら現時点ですでに，GitHubに200万行を越えるKotlinコードが(JetBrainsのプロジェクトは除く)，StackOverflowに700を越える質問が，それぞれ存在するのは事実だ。