Java 11 時代の Java プログラミングスタイルガイド

Java のリリースサイクル が変更され、2019/01 現在の Java の最新バージョンは早 11。文法面での改善も進んでおり、モダンな Java のスタイルにも変化が見られる。この記事では Java 11 時代におけるモダンな Java プログラミングのスタイルをまとめてみたい。

筆者の主観を多分に含むため、その点ご注意を。

# var（ローカル変数の型推論）

- `var` を積極的に利用する。

Java 10 で導入された `var` によるローカル変数の型宣言だが、基本的には使用できる場面では積極的に使用するというスタンスでよいだろう。モダンな言語の多くは同様の型推論を採用しているが、それで問題になったという話は聞かない。

高度に訓練された Java プログラマーにとっては左辺の型定義など IDE が自動補完してくれるので便利さを感じないという意見には一理あるのだが、コードを読むときに限っては Java の左辺の文字数の多さには可読性を著しく損なう冗長さがある。

```java
// before
Owner owner = new Owner();
List<Pet> pets = List.of(new Pet("pochi"), new Pet("tama"));

// after
var owner = new Owner();
var pets = List.of(new Pet("pochi"), new Pet("tama"));
```

上記の例なら大したことはないが、ジェネリクスも含めると Java のクラス名は長くなりがちなので、`var` を使って情報量を減らしてあげた方が読みやすい場面が多いだろう。

# コレクション操作

## unmodifiable

- コレクションを変更不可能にできる箇所ではできるだけ変更不可能にする。

Java の標準コレクションライブラリには `ImmutableList` といった変更不可能性を表すインターフェースは存在しないが、要素の変更を行おうとした時に例外を発生させるようにすることはできる。予期せぬ要素の変更を防止するために、変更不可にできる箇所はできるだけ変更不可にしておいた方がいいだろう。

```java
// Java 9 で追加されたファクトリーメソッドは変更不可能なコレクションを生成する
List.of(1, 2, 3); // unmodifiable
Set.of(1, 2, 3); // unmodifiable
Map.of("keyA", "valueA", "keyB", "ValueB"); // unmodifiable

// Collections クラスにはコレクションの変更不可能なビューを返すメソッドが用意されている。
Collections.unmodifiableList(modifiableList); // unmodifiable

// Java 10 で追加されたファクトリーメソッドによっても既存のコレクションの変更不可能なビューを作成可能
List.copyOf(modifiableList); // unmodifiable

// Java 10 では Stream の Collector として変更不可能なコレクションに変換するメソッドが追加されている
modifiableList.stream().collect(Collectors.toUnmodifiableList());
```

## Stream API

- 極力 for 文を使用せず、Stream API によって処理する。

Java 8 での Stream API の出現によって for 文が活躍する機会はほとんどなくなった。Stream API の宣言的な記述はうまく使用すれば可読性が高く、パフォーマンスの観点からも優れるため、例外的な場面を除いてコレクション操作は Stream API によって行うのがよいだろう。

```java
var beforeList = List.of("a", "b", "c");

// before
var afterList1 = new ArrayList<String>();
for (var str : beforeList) {
  afterList.add(str.toUpperCase());
}

// after
var afterList2 = beforeList
    .stream()
    .map(String::toUpperCase)
    .collect(Collectors.toList());
```

# Null

## Optional

- メソッドの戻り値として `null` が返り得る場合は、`Optional` 型として返す。

Java 8 ではその値が `null` かもしれないことを表す `Optional` 型が追加された。これを使わない理由はないので、`null` が返り得る場合には `null` を直接返すのではなく、常に `Optional` 型として返すようにする。

```java
Optional<String> getName() {
    return Optional.ofNullable(this.name);
}
```

`Optonal` はメソッドの戻り値として使用されることメインに想定されているようなので、メソッドの引数やフィールドでは基本的には使わないようにするのがよいだろう。

## Nullability

- `null` 可否をアノテーションによって表現する。

Kotlin 導入のメリットとしてよく語られるのが null 安全であるというものだが、Java でもそれを部分的に実現する機構が用意されていて、それがアノテーションによる null 可能性の宣言である。これは Java 標準機能として採用されることはなかったため、何らかのサードパーティーライブラリの導入を必要とするが、広く用いられている機構である。

例えば Spring Framework がバージョン 5 から提供しているアノテーションを使うと以下のような表現が可能となる。

```java
public @Nullable Pet getPetByName(@NonNull String name) {
    // 引数 name には null を渡してはならない
    // 返り値 Pet は null になりうる（通常は Optional<Pet> とするほうがよい）
}
```

これによって IDE の静的検査による事前の null 可能性のチェックが可能となる。
![j1WaTnvg.png](https://qiita-image-store.s3.amazonaws.com/0/43205/40f50ef8-d846-25a7-c814-7f39acdf0035.png)

ちなみに、Kotlin から Java のコードを利用する際にもこれらのアノテーションが付与されていることで null 非許容型だと判別してくれるといったメリットもある。

- [Nullability annotations - Calling Java from Kotlin - Kotlin Programming Language](https://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations)

※ 具体的にどのライブラリのアノテーションを使用すべきかというのはちょっと断言できない。おそらく現状一番使用されているのは JSR 305 だと思うのだが、この JSR は休止状態にあって今後も採用の見込みがなく、ライセンス上も使用することは推奨できない状況。Checker Framework が有力な選択肢となりうると思うが、他にも選択肢があるので複数比較して使用するものを決定する必要があるだろう。

参考）
- [nullpointerexception - Which @NotNull Java annotation should I use? - Stack Overflow](https://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use/42695253#42695253)
- [https://qiita.com/ptiringo/items/71c2792e7c553399c2e2#comment-b7026b640ba564ba7b2d](https://qiita.com/ptiringo/items/71c2792e7c553399c2e2#comment-b7026b640ba564ba7b2d)

## Objects.requireNonNull

- メソッドの null 非許容な引数は `Objects.requireNonNull` メソッドを使って早いタイミングで null チェックを行う。

Nullability を表すアノテーションである程度 null の混入を防止することができるが、あくまで静的解析でしか無いため実行時に null が混入した場合には無力である。実行時の null 混入を早めに検知するためにはメソッド内部での null チェックが結局必要となる。

Java 7 で導入された `Objects.requireNonNull` を使えば、簡潔に null 検査を行うことができるので積極的にこれを使っていくとよいだろう。

```java
Pet(@NonNull String name, @NonNull LocalDate birthdate) {
    this.name = Objects.requireNonNull(name);
    this.birthdate = Objects.requireNonNull(birthdate);
}
```

ちなみに IntelliJ であれば、`@NonNull` などのアノテーションが付与された変数の上で Option + Enter することで 自動的に `Objects.requireNonNull` で囲ってくれるオプションを表示してくれるので、これを利用するのが効率的だ。
![aaa](https://qiita-image-store.s3.amazonaws.com/0/43205/6a2301a8-9c7a-bed5-bd84-e9a67d7e6407.png)

# try-with-resources

- リソースのクローズ処理が必要な箇所では常に try-with-resources を使う。

Java 7 で try-with-resource の機構が導入され、リソースのクローズ処理が容易に行えるようになりました。データベースコネクションなど、処理の成功・失敗にかかわらず必ずクローズ処理が必要になるリソースについては常に try-with-resource の機構を使ってクローズ処理を行うのがよいでしょう。

```java
// before
FileInputStream inputStream1 = null;
try {
  inputStream1 = new FileInputStream("foo.txt");
  inputStream1.read();
} finally {
  if (inputStream1 != null) {
    try {
      inputStream1.close();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

// after
try (var inputStream2 = Files.newInputStream(Path.of("foo.txt"))) {
  inputStream2.read();
}
```

# 日時

- Date and Time API を使う。
- Date クラスや Calendar クラス、SimpleDateFormat クラスなどの旧クラス群は特別な理由がない限り使用しない。

Java 8 で導入された Date and Time API によって旧来の Date クラスや Calendar クラス、SimpleDateFormatter クラスなどをほとんど全て置き換えられるようになった。特別な理由がない限り旧来のクラスは使用しないのがよいだろう。

```java
// before
var date = new Date();
var simpleDateFormat = new SimpleDateFormat("yyyy/MM/dd");
System.out.println(simpleDateFormat.format(date));

// after
var localDate = LocalDate.now();
var dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy/MM/dd");
System.out.println(dateTimeFormatter.format(localDate));
```

旧来のクラス群の使いづらさを解消するために使用された Joda-Time などのライブラリも役割を終えたと言えるだろう。

- [Date and Time API 復習 - Qiita](https://qiita.com/opengl-8080/items/d0dc57d64d3a871a8463)

# ファイル操作

- `java.io` パッケージのクラス (Java I/O) よりも `java.nio.file` パッケージのクラス (NIO2) を優先的に使用する。

Java 7 で導入された NIO2 によって Java のファイル操作 API は新しくなっている。基本的には旧来の API は極力使わず、新しい API を使用するという方針で行くのがいいだろう。

```java
// before
var dir = new File("/tmp/dir");
var succeeded = dir.mkdir();
if (succeeded) {
  try {
    new File(dir, "foo.txt").createNewFile();
  } catch (IOException e) {
    e.printStackTrace();
  }
}

// after
try {
  var directory = Files.createDirectory(Path.of("/tmp/dir2"));
  Files.createFile(directory.resolve("foo.txt"));
} catch (IOException e) {
  e.printStackTrace();
}
```

`new File(..)` ではなく `Path.of(..)` および `Files.xxx` を使うことを心がける。

- [Java NIO2 のおさらいメモ - Qiita](https://qiita.com/rubytomato@github/items/6880eab7d9c76524d112)
- [java.io.File のコードを java.nio.Path と java.nio.Files を使って書き直す - Qiita](https://qiita.com/toastkidjp/items/5500521ff5dc0346c2b1)

# モジュール

理解次第追記……。