2026年2月22日日曜日

【Java進化史第23回】Java8でBase64は何がどう変わったのか〜地味だが確かな進化〜

風の噂で聞いた。

Java8でBase64が正式に追加されたらしい。

「いや、前からあっただろう？」

そう思った人も多いはずだ。

確かに、Java7以前でもBase64は使えていた。


// Java7以前（内部API）
import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;

// 内部実装。公式仕様ではない
BASE64Encoder encoder = new BASE64Encoder();
String encoded = encoder.encode("Hello".getBytes());

使えてはいた。

しかし、sun.* は内部API。

将来の保証はない。

そしてJava8で、正式APIが追加された。

■ Java8で追加されたBase64


import java.util.Base64;

String original = "Hello Java8";

// 通常のBase64エンコード
String encoded = Base64.getEncoder()
                       .encodeToString(original.getBytes());

// デコード
String decoded = new String(
        Base64.getDecoder().decode(encoded)
);

java.util.Base64。

内部APIから、正式仕様へ。

これが最大の変化だ。

■ 何がどう変わったのか

① 内部API → 標準APIへ

Java7以前：sun.misc（内部API）
Java8以降：java.util.Base64（正式サポート）

安心して使える。

地味だが、これは大きい。

② 用途別に整理された


// 改行なし（一般的な用途）
Base64.getEncoder();

// URL安全（+ と / を置換）
Base64.getUrlEncoder();

// MIME形式（76文字ごとに改行）
Base64.getMimeEncoder();

以前は用途の区別が曖昧だった。

Java8では、意図がAPIに現れている。

③ 改行仕様が明確になった

通常Encoder：改行しない
MIME Encoder：76文字ごとにCRLF改行

メール添付や一部仕様では、この違いが重要になる。

④ 例外仕様が整理された


try {
    Base64.getDecoder().decode("不正な文字列");
} catch (IllegalArgumentException e) {
    // 不正なBase64文字列
}

decode時の挙動も明確だ。

■ 地味だが、いい進化

Java8はラムダやStreamが目立つ。

しかしその裏で、こうした基盤の整備も行われていた。

派手ではない。

だが確実に実務を支える変更だ。

地味だが、いい進化だなぁと思う。

【Java進化史第22回後編】defaultメソッドの注意点〜どこまで“クラス化”したのか〜

前回、インターフェースに実装を書くという事実に、正直な違和感を覚えた。

今回は、少し冷静に整理してみる。

defaultメソッドは、どこまで許されているのか。

■ defaultメソッドは何ができるのか

まずは単純な例から。


public interface Sample {

    int VALUE = 10; // 定数は持てる（public static final）

    int calc(int x);

    default int doubleCalc(int x) {
        return calc(x) * VALUE;
    }
}

ここで注目すべき点は2つある。

インターフェースは定数（public static final）しか持てない
defaultメソッドは他の抽象メソッドを呼び出せる

つまり、 defaultメソッドは「振る舞いの共通化」はできる。

しかし、状態は持てない。

インスタンスフィールドは宣言できない。コンストラクタもない。

ここは、クラスとは決定的に違う。

defaultメソッドは、クラスの代わりではない。

あくまで、契約の延長線上にある“補助的な実装”だ。

■ 多重継承はどうなるのか

では、インターフェースが複数あったらどうなるのか。


interface A {
    default void hello() {
        System.out.println("A");
    }
}

interface B {
    default void hello() {
        System.out.println("B");
    }
}

class C implements A, B {
}

これはコンパイルエラーになる。

どちらのhelloを使うのか、曖昧だからだ。

Javaは、この曖昧さを許さない。

必ず、実装クラス側で明示的に解決する必要がある。


class C implements A, B {

    @Override
    public void hello() {
        A.super.hello();
    }
}

このように、どのインターフェースの実装を使うかを明示的に指定する。

「なんとなく動く」は許されない。

■ 原則は壊れていない

インターフェースは、今でも状態を持たない。

完全なクラスになったわけではない。

defaultメソッドは、無制限の自由ではない。

制御された拡張である。

だからこそ、長年守られてきた設計思想は、完全に崩れたわけではない。

むしろ、後方互換性を守りながら進化するための、現実的な選択だったと言える。

違和感はある。

だが、無秩序ではない。

そこが、Javaらしさなのかもしれない。

【Java進化史第22回前編】Java8 〜インターフェースに実装を書く？defaultメソッドはアリなのか〜

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


public interface Calculator {

    int add(int a, int b);

    default int subtract(int a, int b) {
        return a - b;
    }
}

class SimpleCalculator implements Calculator {

    @Override
    public int add(int a, int b) {
        return a + b;
    }
}

ここでの読み方はこうだ。

add は従来どおり「実装必須」の抽象メソッド。

一方、default が付いた subtract は、インターフェース側にあらかじめ実装が用意されている。

実装クラスが独自に書かなければ、そのままこの処理が使われる。

つまり、インターフェースが「振る舞いの雛形」を持っている、ということになる。

あれ？

実装していいの？

インターフェースに、処理が書いてある。

しかも、実装クラスでは add しか書いていない。 subtract は自動的に使えてしまう。

正直に言えば、違和感しかなかった。

インターフェースとは「契約」だ。

何をするかを定義する場所であって、どうやるかを書く場所ではない。

少なくとも、私たちはそう教わってきた。

■ なぜ実装を書かなかったのか

理由は単純だ。

責務を分けるためである。

インターフェース＝振る舞いの定義（契約）
クラス＝具体的な実装

役割を分離することで、設計は明確になり、依存関係も整理される。

そして何より、カプセル化が守られる。

■ カプセル化と保守性

実装の詳細はクラス内部に隠される。

外部から見えるのは、メソッドのシグネチャだけ。

だから、保守性と利用者視点の可読性が守られていた。実装が隠蔽されていることで、変更の影響範囲は実装クラス内部に閉じ込められる。利用者は契約（インターフェース）だけを読めばよく、それが長年Javaの安定性を支えてきた。

ただし、これは「半分は真実」である。

確かに利用者にとっては読みやすい。しかし、実装を探すためにクラスを辿らなければならない場面も多かった。

設計が崩れれば、インターフェースはただの形式だけになってしまう。

■ それでも守られてきた原則

それでも、「インターフェースに実装を書かない」という原則は長く守られてきた。

それは単なる文法上の制約ではない。

Javaという言語が大規模開発で信頼されてきた、ひとつの思想だった。

2026年2月21日土曜日

【Java進化史番外編】Java8で「符号なし」が追加？本当か？

そういえば。

Java8で「符号なし」が導入された、とどこかで聞いたことがある。

……え？

Javaって、unsigned無かったよね？

なんで今頃？

ちょっと気になったので、調べてみた。

■ きっかけは、IPアドレス

昔、こんなコードを書いたことがある。


InetAddress addr = InetAddress.getLocalHost();
byte[] ip = addr.getAddress();

System.out.println(ip[0]);

出力：

-64

……は？

IPアドレスって、192とか168じゃなかったか？

なぜマイナスになる？

■ 192って何なのか

例として、


192.168.0.1

この「192」は、 IPアドレスの最初の1バイト（8ビット）である。

IPv4は32ビット。


8ビット × 4 = 32ビット

つまり、IPアドレスは4つのbyteでできている。

192を2進数にすると：

11000000

これが1バイトの正体だ。

■ なぜ -64 になるのか

Javaのbyteは符号付き。


-128 ～ 127

11000000を符号付きとして解釈すると、それは -64 になる。

それだけの話である。

■ Java8ならどう書く？

IP取得方法は変わっていない。 InetAddressも昔のままだ。

変わったのは、読み方である。


InetAddress addr = InetAddress.getLocalHost();  
byte[] ip = addr.getAddress();                  

int first = Byte.toUnsignedInt(ip[0]);

System.out.println(first);

Java8で追加された Byte.toUnsignedInt() によって、符号なしとして読むことができるようになった。

■ 4つ並べると

昔


for (byte b : ip) {
    System.out.print(b + ".");
}


-64.-88.0.1.

Java8


for (byte b : ip) {
    int value = Byte.toUnsignedInt(b);
    System.out.print(value + ".");
}


192.168.0.1.

■ で、結局なにが起きたのか

Java8は、unsigned型を追加したわけではない。

unsignedとして「読む方法」を追加した。

byteの仕様は変わっていない。 intの仕様も変わっていない。

もちろん、boxingやラッパークラスの挙動もそのままである。

既存のコードを一切壊さない。

その範囲でできることを追加した。

値そのものは昔から同じ。

型は増やさず、解釈の手段だけを加えた。

■ なぜ今頃？（少しだけ補足）

Javaは当初、型を増やさない設計を選んだ。

だからunsignedは入らなかった。

だが、ネットワークやビット演算の現場では、 0～255として扱いたい場面が多かった。

そこでJava8で、型は増やさず、解釈メソッドを追加した。

いかにもJavaらしい、後方互換を守る現実解である。

【Java進化史第21回】Java8 〜 ::（メソッド参照）とは何か。どう読めばいいのか〜

若手のコードを見た。

list.forEach(System.out::println);

「:」なら知っている。

でも「::」は知らない。

Javaに、こんな記号あったか？

どこが引数で、どこが処理なのか。

まずは、一度戻る。

■ 昔のJavaに戻る

for (String s : list) {
    System.out.println(s);
}

これなら分かる。

■ 次にラムダに戻る

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

s -> System.out.println(s)

左側が「受け取る引数」。

右側が「実行する処理」。

s を受け取り、println(s) を実行する。

■ 何が省略されたのか

System.out.println(s)

受け取った s を、そのまま println に渡しているだけ。

だから省略できる。

■ ここで :: が出てくる

System.out::println

これは、

s -> System.out.println(s)

を短く書いただけ。

まだ実行していない。

メソッドそのものを渡している。

■ A::B の読み方

A::B

「A の B というメソッドを使う」

A.B() ではない。

呼び出しではなく、メソッドそのものを渡している。

■ 他のパターンも同じ

① 静的メソッド

list.stream()
    .map(s -> Integer.parseInt(s));

↓

list.stream()
    .map(Integer::parseInt);

Integer クラスの parseInt メソッドを使う、という意味。

② 特定オブジェクトのメソッド

Supplier<String> supplier =
    () -> user.getName();

↓

Supplier<String> supplier =
    user::getName;

user の getName メソッドを使う。

③ コンストラクタ参照

Supplier<List<String>> supplier =
    () -> new ArrayList<>();

↓

Supplier<List<String>> supplier =
    ArrayList::new;

ArrayList のコンストラクタを使う、という意味。

これも同じ。

「new を呼び出している」のではなく、

「このコンストラクタを使ってね」と渡している。

■ もう一度まとめる

昔のJava。

for (String s : list) {
    System.out.println(s);
}

ラムダ。

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

メソッド参照。

list.forEach(System.out::println);

意味は同じ。

段階的に省略されているだけ。

■ 何が変わったのか

昔のJavaは、「全部書け」だった。

Java8からは、「同じ意味なら短くしていい」に少し進んだ。

:: は、その象徴。

でも中身は昔と変わらない。

2026年2月19日木曜日

【Java進化史第20回】Java8 〜Optionalとは何か。どう読めばいいのか〜

昔は、こういうコードを何度も書いた。

 User user = findUser(id); if (user != null) { String name = user.getName(); if (name != null) { System.out.println(name); } }

null を確認する。

また null を確認する。

チェックを忘れれば、 NullPointerException。

仕方なかった。

当時のメソッドは、こうだったからだ。

 User findUser(int id);

見つからなければ、null を返す。

だから、呼び出す側で毎回確認していた。

■ Java8では、こう書ける

 Optional<User> findUser(int id);

戻り値が変わった。

null を直接返さない。

値が無い場合は、「空の Optional」を返す。

読むときは、こう読む。

「User が入っているかもしれない箱」

■ Optionalとは何か

まずは宣言。

 Optional<String> name;

意味は、

「String が入るかもしれない箱」。

値がある場合。

 Optional<String> name = Optional.of("Taro");

中身あり。

値が無い場合。

 Optional<String> name = Optional.empty();

中身なし。

これは true / false ではない。

「空の箱」を作っているだけだ。

null かもしれない値を入れる場合。

 Optional<String> name = Optional.ofNullable(value);

value が null なら empty。

値があれば、中身あり。

■ どう使うのか

中身があるか確認する。

 if (name.isPresent()) { System.out.println(name.get()); }

isPresent() は boolean を返す。

get() は中身を取り出す。

※ 中身が無いと例外になる。

デフォルト値を使う場合。

 String result = name.orElse("default");

中身があればその値。

無ければ "default"。

中身があるときだけ処理する。

 name.ifPresent(n -> System.out.println(n));

昔の

 if (user != null)

に近い。

■ NullPointerExceptionは減るのか

昔はこうだった。

 User user = findUser(id); System.out.println(user.getName()); // NPEの可能性

Optional では、

 Optional<User> user = findUser(id);

そのまま user.getName() は書けない。

必ず、

isPresent()、orElse()、ifPresent()

などを通す。

だから、 nullチェック忘れの事故は減る。

ただし、 get() を乱用すれば例外は出る。

■ どこで使うのか

基本は、戻り値。

 Optional<User> findUserById(int id);

見つからない可能性があるメソッド。

フィールドや引数では、あまり使わない。

■ 何が良くなったのか

「nullを返す」から、

「値が無い可能性があると宣言する」へ変わった。

その結果、

nullチェック忘れの事故が減り、コードの意図が少し読みやすくなった。

2026年2月16日月曜日

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

【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 の中に、実装があるのか。

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

ページ