2026年2月16日月曜日

【Java進化史第19回前編】Java8 〜interfaceが壊れた日（@の正体）〜

若手のコードを見て、固まった。

interface に @ が付いている。

しかも、その中に実装らしきものがある。

例えば、こんなコードだ。


@FunctionalInterface
public interface Task {

    void execute();

    default void log() {
        System.out.println("log");
    }
}

@ が付いている。

しかも、実装まである。

え？
interface って、実装書けたっけ？

何が起きているのか、分からなくなった。

■ 混乱は、2つあった

落ち着いて見ると、
混乱は2つあった。

1つ目。
上に付いている「@」。

2つ目。
interface の中にある「実装」。

一気に理解しようとして、止まった。

だから今回は、
まず「@」のほうだけ整理する。

■ @FunctionalInterface が出てきたら

正直、「関数型」という言葉は難しい。

だから私は、こう読むことにした。

「この interface は、メソッドが1つだけです」

それだけだ。


@FunctionalInterface
public interface Converter<T, R> {
    R convert(T input);
}

見るべきなのは、ここ。

抽象メソッドが1つだけ。

もし2つに増やすと、
コンパイルエラーになる。

つまりこれは、

「1メソッドで使います」

という宣言だ。

■ なぜ、わざわざ宣言するのか

では、なぜそんな宣言が必要なのか。

理由はシンプルだ。

うっかり2つ目の抽象メソッドを追加してしまうのを防ぐため。

もし増やせば、コンパイルエラーになる。

つまりこれは、設計のブレを防ぐための安全装置だ。

特別な機能を追加するものではない。

設計の意図を、はっきりさせるための印だ。

■ interface の形は変わっていない

public interface。

メソッド定義。

書き方は昔と同じだ。

@ が付いただけ。

interface 自体が別物になったわけではない。

■ もう1つの混乱

だが、まだ疑問は残る。

なぜ interface の中に、実装があるのか。

それは、@ とは別の進化だ。

Java8は、 interface にもう1つの変化を加えていた。

それが何なのか。

そして、なぜそんな変更が必要だったのか。

次回、整理してみる。

【Java進化史第18回】Java8 〜「@」も読めなかった日

【Java進化史第18回】Java8 〜「@」も読めなかった日〜

若手のコードを見たとき、
固まったことがある。

-> が読めない。
Streamも追えない。

そして、やたらと出てくる「@」。

なんじゃこれ？

■ @ は何者か

調べてみると、
これは「アノテーション」という仕組みだった。

コードに“意味”を追加するための印。
処理そのものを書くものではない。


@Override
public String toString() {
    return name;
}

「ちゃんとオーバーライドしていますよ」
という宣言だ。

もしメソッド名を間違えれば、
「それ、オーバーライドになっていませんよ」と
コンパイル時に教えてくれる。

人間のミスを減らすための仕組みだ。

■ いつからあったのか

アノテーションは、Java5から存在している。

つまり、
私が気づかなかっただけだ。

だがJava8で、
その世界は少し広がった。

■ Javaで使える主なアノテーション一覧（〜Java8）

アノテーション	用途	利用可能バージョン
@Override	正しくオーバーライドしていることを示す	Java5〜（※Java6からインターフェースにも適用可）
@Deprecated	非推奨であることを示す	Java5〜
@SuppressWarnings	コンパイラ警告を抑制する	Java5〜
@SafeVarargs	可変長引数の安全性を保証する	Java7〜
@FunctionalInterface	関数型インターフェースであることを示す	Java8〜
型アノテーション (@Target(TYPE_USE))	型そのものにアノテーションを付けられる	Java8〜

こうして並べてみると、
Java8で増えたものがある。

@FunctionalInterface と、
型アノテーションだ。

■ 型にも付くようになった

Java8から、
アノテーションは「型」にも付けられるようになった。


List<@NotNull String> names;

これまでは


@NotNull List<String> names;

こうだった。

前者は「namesがnullではない」。
後者は「リストの中のStringがnullではない」。

守れる範囲が、少し細かくなった。

■ 読めなかった理由

若手は、これを普通に読む。

私は止まった。

-> と同じくらい、
@ も読めなかった。

だが分かってしまえば、
やっていることはシンプルだ。

コードに意味を足しているだけ。

Java8はラムダだけではない。
@ の世界も、静かに広がっていた。

■ 次回へ

Java8で追加された @FunctionalInterface。
これはラムダと深く関係している。

Javaはどこまで「関数型」に寄ったのか。
次回、そこを見ていく。

2026年2月15日日曜日

【Java進化史第17回】Java8 〜データが壊れた日。forEachが危ない理由〜

昔、データが壊れたことがある。

テストでは動いていた。
だが本番で崩れた。

件数が合わない。
値が欠ける。
ときどき例外も出る。

原因は、スレッドセーフではないクラスだった。

■ スレッドセーフとは

複数のスレッドから同時に触っても、データが壊れないこと。

逆に言えば、同時に触ると壊れるクラスもある。

そして怖いのは、

テストでは再現しないことがある。

タイミング次第だからだ。

■ 並列処理は、昔は怖かった

Java7まで、並列処理を書くには自分で守る必要があった。

synchronizedを付ける。
Concurrent系を使う。
共有変数に気を付ける。

だから私は、並列処理が少し怖かった。

■ Streamでも同じことが起きる

List<String> result = new ArrayList<>();

list.parallelStream()
    .map(Employee::getName)
    .forEach(result::add);   // これ

parallelStreamにすると、複数スレッドが同時にaddする可能性がある。

ArrayListはスレッドセーフではない。

つまり、また壊れる可能性がある。

■ ああ、だからforEachは危ないのか

forEachは、外の変数を触る。

外を触るということは、共有するということだ。

共有は、並列では危ない。

■ collectという書き方

List<String> result =
    list.parallelStream()
        .map(Employee::getName)
        .collect(Collectors.toList());

collectは、外の変数を使わない。

だからparallelでも、安心して書ける。

仕組みの詳しい話までは知らなくていい。

並列にするなら、collectを書く。

■ Stream編、ここまで

最初は、若手の1行が読めなかった。

そこから、

左から読む
何をやるかを書く
forEachは危ないことがある

ここまで来た。

もう、Streamは怖くない。

Java8は、少しだけ味方になった。

【Java進化史第16回】Java8 〜Streamは「どうやるか」ではなく「何をやるか」〜

前回は、Streamを「左から読む」練習をしました。

filter → map → forEach。

左から順番に読めばいい。

それだけで、若手の1行が読めるようになる。

でも、まだモヤモヤが残る

なぜ、こう書くのか。

Java6までの自分には、 for文のほうが自然でした。

for (Employee e : list) {
    if (e.isActive()) {
        System.out.println(e.getName());
    }
}

順番も、処理も、全部自分で書いている。

安心感があります。

Streamは「何をやるか」だけを書く

list.stream()
    .filter(e -> e.isActive())
    .map(e -> e.getName())
    .forEach(System.out::println);

このコードをよく見ると、回し方は書いていません。

どこから回すか
どうやって回すか
順番をどう制御するか

何も書いていない。

書いているのは、

条件で絞る
名前に変換する
出力する

「何をするか」だけです。

動きは1件ずつ“かもしれない”

Streamは内部で、

要素1 → filter → map → forEach
要素2 → filter → map → forEach
...

のように流れていきます。

でも、それを意識しなくていい。

1件ずつ処理するかもしれないし、並列になるかもしれない。

自分は「どうやるか」を考えなくていい。

これが、Streamの価値です。

オブジェクト指向の延長だった

Javaは昔から、実装を隠してきました。

Collectionもそう。

インターフェースで定義し、中身は隠す。

Streamも同じです。

処理のやり方は任せる。

自分は、やりたいことを書く。

そう考えると、少しだけ腹に落ちました。

次回予告

次回は、collectとforEachの違い。

「結果を返す」のはどちらなのか。

ここが分かると、Streamは完成します。

【Java進化史第15回】Java8 〜Streamを読む練習。「左から読む」だけ〜

■ この記事で分かること

Streamを読んで「何をしているか」説明できるようになる
Java6以前でどう書くかが分かる
Streamの内部の動きと価値が分かる

■ まずは読む練習

Streamが怖いのは、何をしているのか分からないからだ。

今日は、たった1つのコードを読む。


names.stream()
     .filter(n -> n.startsWith("S"))
     .map(String::toUpperCase)
     .sorted()
     .forEach(System.out::println);

さて、これは何をしているだろう。

読むポイントはひとつ。

左から順番に読むだけ。

■ 何をしている？

左から順に、日本語にしていく。

names を stream にする
Sで始まるものだけ残す
大文字に変換する
並べ替える
表示する

つまり、

「Sで始まる名前を大文字にして、並べ替えて表示している」

まずは、これが言えればいい。

■ Java6以前ならどう書くか

同じことを、Java6までの書き方で書いてみる。


List<String> result = new ArrayList<String>();

for (String name : names) {
    if (name.startsWith("S")) {
        result.add(name.toUpperCase());
    }
}

Collections.sort(result);

for (String name : result) {
    System.out.println(name);
}

やっていることは同じだ。

回す
条件を確認する
変換する
並べ替える
出力する

Streamは、これを一本の流れで書いているだけだ。

まずはここまで理解できれば十分だ。

■ では内部ではどう動くのか

Java6までなら、基本はこうだ。


for (...) {
    // 1件ずつ順番に処理
}

もし並列化したければ、

スレッドを作る
処理を分割する
同期を取る
競合を防ぐ

あの、バグを生みやすい並列処理を、自分で書く必要があった。

Streamは違う。


names.parallelStream()
     .filter(...)
     .map(...)
     .forEach(...);

これだけで、内部で自動的に分割され、並列処理される。

開発者は並列化のコードを書かなくていい。

回す責任だけでなく、並列化の責任もライブラリに渡した。

通常の stream() の場合は順番に処理される。

だが重要なのは、

Streamは1件ずつかもしれないし、並列かもしれない。それを意識しなくていい設計が価値だ。

「どう回すか」ではなく、「何をするか」だけを書く。

それがJava8の思想である。

■ まとめ

まずは左から順番に読む
日本語にできれば理解できている
Java6で書き直せるなら、もう怖くない
並列化を自分で書かなくていいのが本質

■ 次回予告

では、実際にfor文からStreamへ書き換えてみる。

次回、「Streamを書いてみる」。

【Java進化史第14回】：Java8 〜若手のこの1行が読めない。Streamの衝撃〜（理屈編）

【Java進化史第14回】Java8 〜若手のこの1行が読めない。Streamの衝撃〜（理屈編）

■ この記事で分かること

なぜStreamが読みにくく感じるのか
なぜfor文が見えなくなったのか
Streamが自動でやってくれていること
「どうやるか」から「何をするか」への変化

■ 若手のこの1行で、私は止まった


names.stream()
     .filter(n -> n.startsWith("S"))
     .map(String::toUpperCase)
     .sorted()
     .forEach(System.out::println);

どうも、Sで始まる名前を集めて、
大文字にして、並べ替えているらしい。

……らしい。

しかし、どこで回しているのかが見えない。

なんじゃこりゃ。

■ 私が知っているJava（Java7まで）


List<String> result = new ArrayList<>();

for (String name : names) {
    if (name.startsWith("S")) {
        result.add(name.toUpperCase());
    }
}

Collections.sort(result);

for (String name : result) {
    System.out.println(name);
}

こちらは安心する。
回して、条件を見て、入れて、並べ替えて、出力する。
全部、自分でやっている。

■ Streamの見た目の流れ


names
  ↓
stream()
  ↓
filter
  ↓
map
  ↓
sorted
  ↓
forEach

左から順番に実行されているように見える。

■ しかし実際はこう動く


① パイプライン（処理の設計図）を作る
   ├─ filter
   ├─ map
   └─ sorted

② 終端操作（forEach）が呼ばれた瞬間

③ まとめて一気に実行

filterやmapは、書いた瞬間には動いていない。

動くのは、最後のforEachが呼ばれたときだ。

■ Streamはforの書き換えなのか？

Streamは、forを書かなくていい仕組みだ。

でも、回っていないわけではない。
見えないところで、ちゃんと回っている。

forが消えたのではない。
自分で書かなくてよくなっただけだ。

■ さらに違うところ


names.parallelStream()

これだけで並列化できる。

Java7でも並列処理は書けた。
しかし、スレッド管理や同期を自分で制御する必要があった。

Streamは、そこまで抽象化している。

■ 私の誤解

私は最初、「短く書ける便利機能」だと思った。

しかし違った。

これは、ループを書くという作業を、
Javaに預ける仕組みだった。

楽をしているのではない。
抽象度を一段、上げただけだった。

■ まとめ

Streamはforを消していない
回す仕組みを内部に隠した
並列処理を簡単に扱えるようにした
「やり方」よりも「意図」を書くようになった

■ 次回予告

Streamは、forの書き換えに見える。
私も最初はそう思った。

回すことを、少し楽にしただけの機能だと。

だが、どうもそれだけではない。

なぜなら、filterやmapは、
書いた瞬間にはまだ動いていないからだ。

では、いつ動いているのか。

次回、この1行を分解してみる。

2026年2月14日土曜日

【Java進化史第13回】：エンジニアとしての矜持が許さない〜ラムダはいつ使う？〜

第13回：エンジニアとしての矜持が許さない〜ラムダはいつ使う？〜

■ それでも、まだやれるはずだ

最近、コードを書く機会が減った。

若手が書く。

最近はAIも書く。

設計はする。レビューもする。

だが、自分の手でラムダを書くことは、確実に減っている。

読めるようにはなった。

→ を見ても、もう止まらない。

だが、それで満足していいのか。

エンジニアとしての矜持が、それを許さない。

読めるだけでは足りない。

自分の手で書ける。

迷わず書ける。

若手と同じスピードで、自然に書ける。

俺はまだ、やれるはずだ。

■ なんでもラムダにできるわけではない

ここで一度、冷静になろう。

ラムダは魔法ではない。

「関数型インターフェース」の実装として使えるだけだ。

つまり、

抽象メソッドが1つだけ
処理をその場で渡したいとき

こういうときに使う。

■ 典型例


list.forEach(e -> System.out.println(e));

これは Consumer<T> という関数型インターフェースをラムダで実装している。

■ では、こういう場合は？


public void execute() {
    int count = 0;
    list.forEach(e -> {
        count++;  // コンパイルエラー
    });
}

ローカル変数 count を変更しようとするとエラーになる。

なぜか？

ラムダ内では、ローカル変数は実質 final でなければならない。

つまり、

「外の状態を自由に変更する道具ではない」

ここが重要だ。

■ ここでラムダだ！と言える瞬間

ラムダが最もかっこいい瞬間は、

「処理を渡す」ときだ。


Collections.sort(list, (a, b) -> a.compareTo(b));

昔なら、こうだった。


Collections.sort(list, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

長い。

本質は compare の1行だけなのに。

その「本質だけ」を書ける。

これがラムダの美しさだ。

■ 今日の練習問題（1問）

問題：

次の匿名クラスを、ラムダ式に書き換えよ。


Runnable r = new Runnable() {
    @Override
    public void run() {
        System.out.println("Hello Lambda");
    }
};

■ 解答


Runnable r = () -> System.out.println("Hello Lambda");

Runnable は抽象メソッドが1つ（run）だけ。

だからラムダにできる。

これが判断基準だ。

■ まとめ

ラムダは「関数型インターフェース」の実装
ローカル変数は実質 final
処理を渡すときに最も美しい

読めるようになった。

次は、書けるようになる。

エンジニアとしての矜持を、取り戻す。

■ 次回予告

ラムダは、ここで一区切り。

読めるようになった。書けるようにもなった。

だが――

若手のコードには、まだ壁がある。


list.stream()
    .filter(e -> e.startsWith("A"))
    .map(String::toUpperCase)
    .collect(Collectors.toList());

……長い。

何が返っているのか、一瞬止まる。

次は、ここだ。

Streamを、分解する。

ページ

2026年2月16日月曜日

【Java進化史 第19回 前編】Java8 〜interfaceが壊れた日（@の正体）〜

■ 混乱は、2つあった

■ @FunctionalInterface が出てきたら

■ なぜ、わざわざ宣言するのか

■ interface の形は変わっていない

■ もう1つの混乱

【Java進化史 第18回】Java8 〜「@」も読めなかった日〜

■ @ は何者か

■ いつからあったのか

■ Javaで使える主なアノテーション一覧（〜Java8）

■ 型にも付くようになった

■ 読めなかった理由

■ 次回へ

2026年2月15日日曜日

【Java進化史 第17回】Java8 〜データが壊れた日。forEachが危ない理由〜

■ スレッドセーフとは

■ 並列処理は、昔は怖かった

■ Streamでも同じことが起きる

■ ああ、だからforEachは危ないのか

■ collectという書き方

■ Stream編、ここまで

【Java進化史 第16回】Java8 〜Streamは「どうやるか」ではなく「何をやるか」〜

でも、まだモヤモヤが残る

Streamは「何をやるか」だけを書く

動きは1件ずつ“かもしれない”

オブジェクト指向の延長だった

次回予告

【Java進化史 第15回】Java8 〜Streamを読む練習。「左から読む」だけ〜

■ この記事で分かること

■ まずは読む練習

■ 何をしている？

■ Java6以前ならどう書くか

■ では内部ではどう動くのか

■ まとめ

■ 次回予告

【Java進化史 第14回】Java8 〜若手のこの1行が読めない。Streamの衝撃〜（理屈編）

■ この記事で分かること

■ 若手のこの1行で、私は止まった

■ 私が知っているJava（Java7まで）

■ Streamの見た目の流れ

■ しかし実際はこう動く

■ Streamはforの書き換えなのか？

■ さらに違うところ

■ 私の誤解

■ まとめ

■ 次回予告

2026年2月14日土曜日

第13回：エンジニアとしての矜持が許さない 〜ラムダはいつ使う？〜

■ それでも、まだやれるはずだ

■ なんでもラムダにできるわけではない

■ 典型例

■ では、こういう場合は？

■ ここでラムダだ！と言える瞬間

■ 今日の練習問題（1問）

■ 解答

■ まとめ

■ 次回予告

【Java進化史第19回前編】Java8 〜interfaceが壊れた日（@の正体）〜

【Java進化史第18回】Java8 〜「@」も読めなかった日〜

【Java進化史第17回】Java8 〜データが壊れた日。forEachが危ない理由〜

【Java進化史第16回】Java8 〜Streamは「どうやるか」ではなく「何をやるか」〜

【Java進化史第15回】Java8 〜Streamを読む練習。「左から読む」だけ〜

【Java進化史第14回】Java8 〜若手のこの1行が読めない。Streamの衝撃〜（理屈編）

第13回：エンジニアとしての矜持が許さない〜ラムダはいつ使う？〜