ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

30

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

利用中のプログラミング言語やプラットフォームの新

リリースほど、ソフトウェア開発者コミュニティが待ち望むものはそうありません。Java開発者も例外ではありません。実際、Java開発者が新リリースに寄せる期待は、他の言語の開発者よりも大きいでしょう。そう遠くはない昔、Javaを生み出したSunと同様、Javaもまた衰退していくように思われた時代があったことも、その理由の1つです。一度終わりかけて再起したのですから、いっそう大事に思えるものです。しかしJavaの場合、新リリースへの熱狂の理由はそれだけではありません。前リリースでは実現されず、Java開発者の多くが（数十年とは言わないまでも）長年求め続けてきた「最新型の」言語機能が、Java 8でようやく新たに実現されるのです。

言うまでもなく、この熱狂を呼ぶJava 8の言語機能こそ、この全2回シリーズのテーマでもある、ラムダ式（別名クロージャ）です。言語機能というものは、ある程度のサポートが背後になければ、その便利さや面白さが分か

らないこともよくあります。Java 7のいくつかの機能はまさにこの表現に当てはまります。たとえば、数値リテラルの機能拡張は、実際にはほとんどの開発者にとって魅力的に映りませんでした。

しかし、Java 8の関数リテラルでは、Java言語の中核が変更されるばかりでなく、関数リテラルを使いやすくするための言語機能もいくつか追加されます。さらに、関数リテラルの機能を直接利用するために、ライブラリも一部改良されます。これらの変更によって、Javaでの開発が容易になります。

Java Magazineでは以前にもラムダ式に関する記事を掲載しています。しかし、執筆以降に構文やセマンティクスが変更された可能性があり、また、過去の記事に目を通す時間のない方のためにも、本記事では読者がラムダ式の構文についてまったく知らないことを想定しています。 注：本記事は、Java SE 8プレリ

リース版に基づき説明します。そのため、本記事には、最終リリースの公開時点では正確でない内容が含まれる可能性がありま

す。構文およびセマンティクスは、最終リリースまでに変更されることがあります。

ラムダ式について、公式の詳細な説明が必要な場合は、Brian Goetz氏の論文（『State of the Lambda: Libraries Edition』）や、その他Project Lambdaホームページで公開されている文献が貴重な参考資料となります。

背景知識：ファンクタJavaでの関数オブジェクト（ファンクタとも呼ばれます）の使用については、Javaコミュニティでは有用でも必要でもないと強く主張していましたが、実際には必要とされる場面が常にありました。初期のJavaでは、GUIの構築時に、ウィンドウを開く/閉じる、ボタンを押す、スクロールバーを動かすといったユーザー・イベントに応答するために、何ブロックものコードを記述する必要がありました。

Java 1.0のAbstract Window Toolkit（AWT）アプリケーションは、C++にすでにあった機能と同様に、ウィンドウ関連のクラスを拡張して、選択したイベント・メソッドをオーバーライドするという方式でした。しかし、この方式は扱いづらく実用性に欠けると判断されました。そのため、SunはJava 1.1で、一連の「リスナー」と呼ばれるインタフェ

ースを導入しました。各リスナーには1つ以上のメソッドがあり、メソッドのそれぞれがGUI内部の1つのイベントに対応します。

また、リスナー・インタフェースやそのメソッドを実装するクラスを記述しやすくするため、Sunはインナー・クラスを導入しました。インナー・クラスでは、クラス名を指定しなくても、既存クラスのボディ内部に実装クラスを記述できます。至る所で見かけるこのようなインナー・ク

Java 8のラムダ式について知る

TED NEWARD

パート1

Java 8：ラムダ式

写真： PHIL SALTONSTALL

CODE = OBJECT

Javaが進化し成熟

するにつれ、一連の

コード・ブロックを

オブジェクト（実際

はデータ）として扱

うことが、単に便利

なだけではなく必

要にもなる分野が

増えました。

Ted Neward （@tedneward）： Neudesicのアーキテクチャ・コンサルタント。複数の専門家グループに貢献。『Effective Enterprise Java』

（Addison-Wesley Professional、2004年）、『Professional F# 2.0』

（Wrox、2010年）などの著書多数。Java、Scalaをはじめとするテクノロジー記事の掲載やカンファレンスでの講演も多い。

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

31

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

ラスは、匿名インナー・クラスと呼ばれます（なお、リスナーはJavaの歴史で登場する数々の要素のほんの一例に過ぎません。後ほど確認しますが、リスナーと同じく「中心的な」インタフェースには、RunnableやComparatorなどもあります）。

インナー・クラスは、構文とセマンティクスの両面において、少し奇妙なところがありました。たとえば、インナー・クラスが静的インナー・クラスであるかインスタンス・インナー・クラスであるかは、特定のキーワードの有無ではなく、インスタンス作成時のレキシカル・コンテキストによって判断されました（ただし静的インナー・クラスは、staticキーワードを使用して明示的に指定することもできます）。実際の問題として、採用試験などのプログラミング課題でリスト1aと1bのようなコードが取り上げられた際は多くの誤答が見られました。

Java開発者はもっぱら、インナー・クラスのような「機能」はせいぜいプログラミング課題で扱うくらいで、一般的な状況では使用しない言語機能なのだと納得していました。必要になるときもありますが、その場合でもたいていは、イベント処理の目的でのみ使用しました。

さらなる進化へ構文やセマンティクスは不格好でも、システムは機能しました。Javaが進化し成熟するにつれ、一連のコード・ブロックをオブジェクト（実際はデータ）として扱うことが、単に便利なだけではなく必要にもなる分野が増えまし

た。Java SE 1.2で改良されたセキュリティ・システムでは、異なるセキュリティ条件下で実行させるコード・ブロックを渡すという方法が便利だと判断されました。同じくJava SE 1.2に搭載された改良版のCollectionクラスは、ソート済みコレクションに対してソート順を指定する方法を把握するために、特定のコード・ブロックを渡す方法が便利だと判断されました。また、Swingでも、

「ファイルを開く」ダイアログ・ボックスや「ファイルを保存」ダイアログ・ボックスで表示するファイルを指定するために、特定のコード・ブロックを渡す方法が便利だと判断されました。同様の事例は多数見られました。記述した本人しか好まないような分かりづらい構文がしばしば使用されたものの、こうしたコード自体は機能していました。

しかし、関数型プログラミングの考え方がプログラミングの主流になり始めたときには、ほとんどのJava開発者が諦めました。関数型プログラミングをJavaで実現すること自体は可能でしたが（こちらに格好の事例があります）、Javaで記述する関数型プログラミングは、何といっても冴えない扱いにくいものでした。多数ある主流のプログラミング言語では、コード・ブロックの定義や受け渡しの機能、および後で実行できるようにコード・ブロックを保管できる機能が言語側で十分にサポートされています。Javaもさらなる進化を遂げ、そのような主流の言語に加わる必要がありました。

Java 8：ラムダ式、型推論、レキシカル・スコープJava 8では、前述のようなコード・ブロックを記述しやすくするための複数の言語機能が導入されます。その中でも重要な機能はラムダ式です。ラムダ式は、くだけた表現としてクロージャや匿名メソッドと呼ばれることもあります（クロージャと呼ばれる理由については後ほど説明します）。それでは、これらの点について1つずつ説明していきます。

ラムダ式：ラムダ式は基本的には、後で実行するメソッドの実装を簡潔に記述するための手法です。たとえば、以前はリスト2に示すようにRunnableを定義しました。リスト2では、匿名インナー・クラス構文を使用していますが、基本的な概念を表現するコード行が過度に多くなるという「縦の問題（vertical problem）」が明らかに見られます。一方、Java 8のラムダ式構文では、同じ内容のコードをリスト3のように記述できます。

class InstanceOuter { public InstanceOuter(int xx) { x = xx; }

private int x;

class InstanceInner { public void printSomething() { System.out.println("The value of x in my outer is " + x); } }}

class StaticOuter { private static int x = 24;

リスト1a リスト1b リスト2

すべてのリストのテキストをダウンロード

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

32

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

いずれのコードも結果は同じで、Runnable実装オブジェクトのrun()メソッドが呼び出され、コンソールに何らかの文字列が出力されます。しかし、内部的には、Java 8で記述したリスト3のコードではRunnableインタフェースを実装する匿名クラスを生成する以外にも、少し処理が加えられます。その処理の一部は、Java 7で導入されたinvoke dynamicバイトコードに関係します。本記事では詳細には説明しませんが、ラムダ式構文の結果、単なる匿名クラスのインスタンス以上のものができると覚えておきましょう。

関数型インタフェース：Runnableインタフェースは、Callable<T>インタフェース、Comparator<T>インタフェース、およびJava内部ですでに定義されているその他の多数のインタフェースと同様に、Java 8で関数型インタフェースと呼ばれるものです。関数型インタフェースの条件として、実装されるメソッドが1つだけ存在する必要があります。関数型インタフェースにより、構文が簡潔になります。インタフェースのどのメソッドをラムダ式で定義しようとしているかが曖昧ではなくなるためです。

Java 8の設計者は、@FunctionalInterfaceというアノテーションを提供することを決定しています。このアノテーションは、インタフェースがラムダ式で使用されることを単に明示するためのものであり、コンパイラでは必要とされません。つまり、コンパイル時には、アノテーションではなくインタフェースの構造から、そのインタフェースが「関数型インタフェースであるこ

と」が判断されます。本記事ではこれ以降も、Runnableイ

ンタフェースとComparator<T>インタフェースを実際の例として利用しますが、これらのインタフェースには、「メソッドが1つのみである」という関数型インタフェースの制約に従っている点を除き、特別なところはありません。開発者は、以下のインタフェースのように、ラムダ式のインタフェース・ターゲット型となる新しい関数型インタフェースをいつでも定義できます。

このSomethingインタフェースは、RunnableやComparator<T>とまったく同様に正当かつ適切な関数型インタフェースです。このインタフェースについては、ラムダ式のいくつかの構文を本記事で習得した後に、再度取り上げます。

構文：Javaにおけるラムダ式は、基本的には3つの部分で成り立っています。1つ目は括弧で囲まれた一連のパラメータ、2つ目は矢印、3つ目はボディです。ボディには、1つの式か1つのJavaコード・ブロックのいずれかを記述できます。リスト2の例では、runにパラメータは指定されておらず、戻り型はvoidです。したがって、パラメータも戻り値もありません。一方、Comparator<T>を使用した例では、ラムダ式の構文がやや明確になります（リスト4）。Comparatorが2つの文

字列を引数として受け取り整数を返すこと、およびその戻り値は負数（「～未満」の場合）、正数（「～より大きい」場合）、0（「～と等しい」場合）のいずれかとなることを覚えておいてください。

ラムダ式のボディに複数の式を指定する必要がある場合、通常のJavaコード・ブロックと同様に、returnキーワードで戻り値として式を返すことができます（リスト5）。 なお、リスト5にもある波括弧をコード内のどの場所に置くかは、Javaの各種掲示板やブログで今後数年にわたって議論されるでしょう。ラムダ式のボディ内で実行可能な処理についてはいくつかの制約がありますが、そのほとんどは非常に直感的なものです。ラムダ式のボディにはラムダ式の外側に抜ける「break」や「continue」は記述できない、あるいは、ラムダ式が値を返す場合はすべてのコード・パスで値を返すか例外をスローする必要がある、などの制約があります。これらの制約は標

準的なJavaメソッドとほぼ同じルールであり、それほど意外なものはありません。

型推論：Java以外の一部の言語でこれまでに評価の高かった機能の1つが、型推論という考え方です。この考え方は、開発者がパラメータの型付けを何度も行うのではなく、コンパイラがパラメータの型を推論できるほど十分にスマートであるべきだというものです。 たとえば、リスト5のComparatorを考えてみます。ターゲットの型がComparator<String>の場合、このラムダ式に渡されるオブジェクトは必ず文字列（または文字列の何らかのサブタイプ）になります。文字列でない場合、このコードはそもそもコンパイルを通りません（なお、この考え方自体は新しいものではなく、「継承の基礎」と言えます）。

この場合、lhsとrhsの各パラメータの前にあるString宣言は完全に冗長で

interface Something { public String doit(Integer i);}

すべてのリストのテキストをダウンロード

public static void main(String... args) { Runnable r2 = () -> System.out.println("Howdy, world!"); r2.run(); }

リスト3 リスト4 リスト5

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

33

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

す。Java 8で強化された型推論機能によって、これらの型の宣言は任意になります（リスト6）。

言語仕様には、ラムダ式の正式な型を明示的に宣言することが必要になるケースについて、明確なルールが定められる予定です。ただし、ほとんどの場合に、例外的なケースではなくデフォルトとして、ラムダ式に対するパラメータの型の宣言を完全に省略できるようになります。

Javaのラムダ式構文による興味深い副作用の1つとして、Javaの歴史の中で初めて、補助情報が何もない場合に、Object型の参照に代入できないというケースが登場します（リスト7）。

リスト7では、コンパイラにより、Objectが関数型インタフェースではないというエラーが示されます。ただし、実際の問題は、このラムダ式で実装すべき関数型インタフェースがどれであるのか（Runnableなのか別のものなのか）をコンパイラでは完全には推論できないことです。この場合、リスト8のように、使い慣れたキャストを使用することで、補助情報をコンパイラに示すことができます。

前述のとおり、ラムダ式はあらゆるインタフェースで使用できるため、カスタム・インタフェースへと推論されるラムダ式も、同じように容易に推論されます

（リスト9）。 ところで、ラムダ式の型シ

グネチャにおいて、プリミティブ型は、それぞれに対応するラッパー型と同様に有効です。

この型シグネチャでプリミティブ型を使用できる点についても新しい考え方ではありません。Java 8では、Javaで長期間維持されてきた原則、パターン、構文が新機能にもそのまま適用されます。この点についてまだご存じでなければ、少しの時間をかけてコード内の型インタフェースについて調べるこ

とで、理解が深まります。 レキシカル・スコープ：一方で、新しい考え方も1つあります。ラムダ式のボディ内でコンパイラが名前（識別子）を取り扱う方法が、インナー・クラスでの取り扱い方法とは異なります。ここで、リスト10のインナー・クラスの例を考えます。リスト10のコードを実

行すると、筆者のマシンでは「Hello$1@f7ce53」という直感的ではない文字列が出力されます。

この理由は単純で、匿名のRunnableの実装内では、thisキーワードとtoStringの呼出しの両方が、式を満足するもっとも内側のスコープである、匿名インナー・クラスの実装にバインドされるためです。

この例では、HelloクラスのtoStringの出力が得られるように見えますが、そうするためには、Java仕様のインナー・クラスの説明にある「アウター・クラス

のthis」構文を使用して、リスト11のように明示的に修飾する必要があります。それでは、「アウター・クラスのthis」のような構文は直感的でしょうか。

率直に言って、この分かりにくさはインナー・クラスがその有用性を発揮できず、混乱を招くだけとなった部分の1つです。たしかに、thisキーワードがこのようにむしろ直感的ではない構文となっている背景には、ある程度は筋の通った理由があります。しかしそれは、政治家が特権を持つことは筋が通っていると言うようなものです。

一方、ラムダ式にはレキシカル・スコープが適用されます。つまり、ラムダ式

の定義の周囲にある環境が、自身の1つ外側のスコープであると認識されます。そのため、リスト12のラムダ式の例は、2つ目のHelloネスト・クラスの例（リスト11）と同じ結果になりますが、はるかに直感的な構文になっています。

なお、この結果から分かるように、thisはラムダ式そのものは参照しません。このことが重要になる場合もありますが、そのような状況はごくまれです。さらに、そのような状況（たとえば、ラムダ式でそのラムダ式自身を返したい場合など）になっても、比較的簡単に使用できる方法が別にあります。この方法については、後ほど説明します。

すべてのリストのテキストをダウンロード

public static void main(String... args) { Comparator<String> c = (lhs, rhs) -> { System.out.println("I am comparing" + lhs + " to " + rhs); return lhs.compareTo(rhs); }; int result = c.compare("Hello", "World"); }

リスト6 リスト7 リスト8 リスト9 リスト10 リスト11

スコープを調べるラムダ式にはレキシカル・スコープが適用されます。つまり、ラムダ

式の定義の周囲にあ

る環境が、自身の1つ

外側のスコープである

と認識されます。

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

34

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

変数のキャプチャ：ラムダ式がクロージャと呼ばれる理由の1つは次のとおりです。関数リテラル（前項までに紹介したような形式の関数）は、その関数リテラルを取り囲むスコープ（エンクロージング・スコープ）内にある（かつ、その関数リテラルの外側にある）変数の参照を「閉じ込める（close over）」ことができます。Javaの場合、エンクロージング・スコープは通常、ラムダ式が定義されているメソッドとなります。インナー・クラスでもこのような構造は可能です。しかし、インナー・クラスの場合、エンクロージング・スコープからは「final」の変数しか参照できないという制約がありました。これは、これまでJava開発者の頭を悩ませてきたインナー・クラスに関する数々のテーマのうちでも、特に重要なものです。

ラムダ式によってこの制約が緩和されます。ただし、その程度は少しだけです。変数の参照が「事実上final」である場合、つまりfinal修飾子がなくとも変数の内容が不変である場合、ラムダ式はその変数を参照できます（リスト13）。messageは、ラムダ式が定義された場所を取り囲むmainメソッドのスコープ内において変更されないため、事実上finalです。そのため、rに格納されるRunnableラムダ式の内部から参照できます。

表面的には何でもないように思えることですが、ラムダ式のセマンティクスのルールは、Javaの全体的な性質を変えるものではないことを覚えておいてください。すなわち、参照先のオブジェクトは、ラムダ式が定義された場所の後でもアクセスでき、変更できます（リ

スト14）。従来のインナー・クラスの構文やセ

マンティクスに精通している鋭い開発者は、インナー・クラス内で参照され、

「final」宣言された参照にも同じことが当てはまることを思い出すでしょう

（final修飾子が、参照先のオブジェクトではなく、参照のみに適用されている場合）。Javaコミュニティの視点から判断して、このことがバグであるか機能の1つであるかは今後に委ねられますが、現状はこれまで説明したとおりです。予想外のバグが発生しないように、開発者はラムダ式の変数のキャプチャ方法について理解しておくのが賢明でしょう（実は、この振る舞いも新しいものではなく、コード量を少なくしコンパイラでの処理を増やすことで、既存のJava機能を作り直しているだけです）。

メソッド参照：前項までに説明したラムダ式はすべて匿名リテラルであり、ラムダ式の定義は使用する時点で行いました。1回限りの動作においてはこの方法で十分良いのですが、複数の場所で同じ振る舞いを必要とする場合は、あまり上等な手段ではありません。たとえば、次のPersonクラスを考えます

（今のところ、カプセル化が不適切である点については気にしないでください）。

class Person { public String firstName; public String lastName; public int age;});

PersonをSortedSetに格納する場合や、何らかの形式のリスト内でソートする必要がある場合、Personインスタンスをソートするための異なる複数のメカニズムが必要になります。たとえば姓でソートする場合、名でソートする場合などがあります。この目的でComparator<T>を使用します。Comparator<T>インスタンスを渡すことで、適用するソート方法を定義できるのです。

たしかに、ラムダ式によって、リスト15のようにソート用のコードが記述しやすくなります。しかし、名を基準としたPersonインスタンスのソートは、コードベース内で何度も実行する可能性があります。この種のアルゴリズムを何度も記述することは、明らかにDRY（Don't Repeat Yourself、「重複の排除」）原則に違反します。

ComparatorをPerson自体のメンバーとして取り込むことはたしかに可能です（リスト16）。そうすれば、他の静的フィールドと同じように、Comparator<T>も参照できるようになります（リスト17）。正直に言えば、関数型プログラミングの熱心な支持者であれば、このようなスタイルを好むでしょう。関数をさまざまな方法で組み合わせることができるからです。しかし、このようなスタイルは、従来

のJava開発者にとっては違和感があります。従来は、Comparator<T>のシグネチャに合うメソッドを作成し、そのメソッドを直接使用するだけでした。この方法こそ、メソッド参照で実現できることです（リスト18）。コロン2つを使用してメソッド名を指定するスタイルに注目してください。このスタイルでは、コンパイラに対して、メソッド・リ

class Hello { public Runnable r = () -> { System.out.println(this); System.out.println(toString()); };

public String toString() { return "Hello's custom toString()"; }}

リスト12 リスト13 リスト14 リスト15

すべてのリストのテキストをダウンロード

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

35

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

テラルではなく、Personに定義されたcompareFirstNamesメソッドをこの場所で使用することを指示しています。

好奇心の強い読者のために、別の方法も紹介しておきます。その方法とは、次のようにcompareFirstNamesメソッドを使用してComparator<Person>インスタンスを作成することです。

さらに、もっと簡潔に記述するために、新しいライブラリ機能の一部を利用して次のように記述し、構文上のオーバーヘッドの一部を完全になくすこともできます。この方法は、高次の関数（大まかに言えば、関数を渡す関数）を利用して、前のコード全体を事実上なくし、次のように1行で記述してメモリをほぼ消費しない形にしたものです。

この例は、ラムダ式や、ラムダ式に伴う関数型プログラミングの各種技術が非常に強力であることを示す好例です。

仮想拡張メソッド：しかし、インタフェースには、よく言われる欠点もあります。その1つは、その実装が疑いようもなく明白な場合でも、デフォルトの実装を記述できないことです。たとえば、架空のRelationalインタフェースを考えます。このインタフェースは、比較メ

ソッド（「～より大きい」、「～未満」、「～以上」など）に似た一連のメソッドを定義するものです。これらのメソッドのいずれか1つを定義すれば、その1つ目を参考にして他のメソッドの定義方法も簡単に把握できます。実際、すべてのメソッドは Comparable<T>のcompareメソッドを参考にして定義できます

（compareメソッドの定義内容が前もって分かっている場合）。しかし、インタフェースにはデフォルトの振る舞いを記述できません。また、抽象クラスはクラスの一種で、潜在的なサブクラスの実装継承スロットを1つ占有します。しかし、Java 8では、前述の関数リテ

ラルが広範に使用されるようになったため、インタフェースの「インタフェースらしさ」を損なうことなくデフォルトの振る舞いを指定できることの重要性が高まっています。そのため、Java 8では仮想拡張メソッドが導入されます（以前の草案ではdefenderメソッドと呼ばれていたものです）。仮想拡張メソッドは基本的に、実装クラスでメソッドの実装が記述されない場合に、インタフェース側でそのメソッドのデフォルトの振る舞いを指定できるようにするものです。

ここで少し、Iteratorインタフェースを考えてみます。現在、3つのメソッド

（hasNext、next、remove）があり、各メソッドには定義が必要です。しかし、一連の反復処理において次（next）のオブジェクトを「スキップ」できる機能があれば便利でしょう。さらに、Iteratorの実装は、上記3つのメソッドを参考にして容易に定義できるため、リスト19のように実装できます。

Javaコミュニティの参加者の中には、仮想拡張メソッドは、インタフェースの宣言性を弱め、Javaで多重継承を許す図式を作り出してしまうメカニズムに過ぎないと嘆く人もいます。この懸念はある程度は的を射ています。特に、（クラスが複数のインタフェースを実装し、それらのインタフェースに同じ名前のメソッドがあり、それらのメソッドのデフォルト実装が異なっている場合における）デフォルト実装の優先順位に関するルールについて、今後念入りに調査する必要があるためです。

しかし、仮想拡張メソッドは名前のとおり、既存のインタフェースを拡張するための強力なメカニズムであり、拡張されたメソッドをある種の二流の機能に下げるものではありません。このメカニズムを使用すれば、たとえばオラクルが、開発者に異なる種類のクラスの追跡作業を求めることなく、既存のライブラリに対して強力な振る舞いを追加できます。開発者がSkippingIteratorクラスをサポートするコレクションを使用するために、ダウンキャストを指定する必要はありません。実際、変更し

Comparator<Person> cf = Person::compareFirstNames;

Arrays.sort(people, comparing( Person::getFirstName));

class Person { public String firstName; public String lastName; public int age;

public final static Comparator<Person> compareFirstName = (lhs, rhs) -> lhs.firstName.compareTo(rhs.firstName);

public final static Comparator<Person> compareLastName = (lhs, rhs) -> lhs.lastName.compareTo(rhs.lastName);

public Person(String f, String l, int a) { firstName = f; lastName = l; age = a; }

public String toString() { return "[Person: firstName:"+ firstName + " " + "lastName:"+ lastName + " " + "age:"+ age + "]"; }}

リスト16 リスト17 リスト18 リスト19

すべてのリストのテキストをダウンロード

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2013

JAVA TECH

36

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//java architect /

なければならないコードは存在せず、いかなる時期にコーディングされたIterator<T>にも、自動的にこのスキップの振る舞いが追加されます。

Collectionクラス内で行われる変更の大部分が、仮想拡張メソッドによってもたらされます。既存のCollectionクラスにも新しい振る舞いを追加でき、しかもそのためにコードをまったく変更する必要がないというのは朗報でしょう。ただし残念ですが、この話題の詳細については、このシリーズの次回の記事までお待ちください。

まとめラムダ式は、Javaコードの記述方法と設計方法の両方に多くの変化をもたらします。これらの変化の一部は、関数型プログラミング言語を参考としており、コーディングに対するJavaプログラマの考え方を変えるものです。この変化はチャンスでもあり、面倒でもあります。

このシリーズの次回の記事では、ラムダ式がもたらす変化がJavaライブラリに与える影響について詳細に説明します。また、新しいAPI、インタフェース、クラスの導入によって、新しい設計アプローチがどのように切り開かれるのかについても少し説明します。インナー・クラス構文が扱いにくいために、以前では実践できなかった設計アプローチです。

Java 8は本当に面白いリリースになりそうです。さあ、覚悟を決めて、新たな世界に飛び立ちましょう。</article>

LEARN MORE• Brian Goetz：『State of the Lambda: Libraries Edition』

• Project Lambdaホームページ

• 「Maurice Naftalin's Lambda FAQ」

Discover All Things Java

• Experience the latest advancements

• 500+ educational sessions

• Expand your development skills

• 100+ product demos

• Meet technology leaders

oracle.com/javaone

REGISTER NOWSave $200 by Sept. 20

Sept. 22 - 26, San Francisco

Bronze SponsorGold Sponsor

Bronze SponsorGold Sponsor

Bronze SponsorGold Sponsor