ラムダ式を使用すると、単一ユニットの動作をカプセル化して他のコードに渡すことができます。 ラムダ式は、プロセスが完了したとき、またはプロセスでエラーが検出されたときに、ある特定のアクションがコレクションの各要素に対して実行されるようにする場合に使用できます。 ラムダ式は、次の機能でサポートされています。
メソッド参照は、すでに名前が付いているメソッドのためのコンパクトで読みやすいラムダ式です。
デフォルト・メソッドにより、ライブラリのインタフェースに新しい機能を追加でき、古いバージョンのライブラリのインタフェース用に記述されたコードとのバイナリ互換性が確保されます。 それらは、1つの実装と、メソッド・シグネチャの先頭にdefault
キーワードを持つインタフェース・メソッドです。 さらに、インタフェース内にstaticメソッドを定義することもできます。
「Java SE 8でのラムダ式とストリームを利用する新しいAPIと拡張API」では、ラムダ式とストリームをうまく利用する新しいクラスと拡張されたクラスについて説明されています。
型推論の改善 - Javaコンパイラでは、ターゲット型付けを利用してジェネリック・メソッド呼出しの型パラメータを推論します。 式のターゲット型とは、Javaコンパイラが式の使われている場所に応じて予測するデータ型です。 たとえば、Java SE 7では代入文のターゲット型を型推論に使用できます。 しかし、Java SE 8ではより多くの状況でターゲット型を型推論に使用できます。 もっとも顕著な例は、メソッド呼出しのターゲット型を使用して、その引数のデータ型を推論することです。
次に例を示します。
List<String> stringList = new ArrayList<>(); stringList.add("A"); stringList.addAll(Arrays.asList());
差し当たりジェネリクスを無視すると、addAll
メソッドはその引数としてCollection
インスタンスを予測し、Arrays.asList
メソッドはList
インスタンスを返します。 これが機能するのは、List
がCollection
のサブ型であるからです。
次に、ジェネリクスを考慮に入れると、addAll
のターゲット型はCollection<? extends String>
となり、Arrays.asList
はList<T>
インスタンスを返します。 この例では、Java SE 8のコンパイラは型変数T
の値がString
であることを推論できます。 このコンパイラは、Collection<? extends String>
というターゲット型からこれを推論します。
Java SE 7以前のコンパイラは、ターゲット型付けを使用してメソッド・コール引数の型を推論しないため、このコードを受け入れません。 たとえば、Java SE 7のコンパイラは次のようなメッセージを生成します。
error: no suitable method found for addAll(List<Object>) ...
method List.addAll(Collection<? extends String>) is not applicable (actual argument List<Object> cannot be converted to Collection<? extends String> by method invocation conversion)
したがって、このようにJavaコンパイラが型を推論できない状況では、型証明を使用して型変数の値を明示的に指定する必要があります。 たとえば、次はJava SE 7で機能します。
List<String> stringList = new ArrayList<>(); stringList.add("A"); stringList.addAll(Arrays.<String>asList());
詳細は、Javaチュートリアルの次のセクションを参照してください。
Java型に関する注釈 - 型が使用されているどの場所にも注釈を適用できるようになりました。 プラガブルな型システムと組み合わせて使用すると、コードの型チェックをより強力に行うことができます。 詳細は、Javaチュートリアルの注釈に関する新しいレッスンの型注釈およびプラガブルな型システムに関するトピックを参照してください。
繰返し注釈 - 同じ注釈型を同じ宣言や型の使用箇所に何度も適用できるようになりました。 詳細は、Javaチュートリアルの注釈に関する新しいレッスンの繰返し注釈に関するトピックを参照してください。
メソッド・パラメータのリフレクション - java.lang.reflect.Executable.getParameters
メソッドを使用して、任意のメソッドまたはコンストラクタの仮パラメータの名前を取得できます。 (Method
およびConstructor
クラスはExecutable
クラスを拡張するため、Executable.getParameters
メソッドを継承します。) ただし、デフォルトでは仮パラメータの名前は.class
ファイルに格納されません。 仮パラメータの名前を特定の.class
ファイルに格納し、Reflection APIで取得できるようにするには、javac
コンパイラの-parameters
オプションを使用してソース・ファイルをコンパイルします。 Javaチュートリアルのメソッド・パラメータの名前の取得に関するトピックを参照してください。
byte
、short
、int
、およびlong
)を2進法で表現することもできます。 バイナリ・リテラルを指定するには、数値に接頭辞0b
または0B
を付加します。 _
)を含めることができます。 この機能を使用すると、たとえば数値リテラルの桁の集まりを分離することで、コードの可読性を向上させることができます。 switch
文の式にString
クラスを使用できます。<>
)で置き換えることができます。 この山カッコのペアは、非公式にダイアモンドと呼ばれています。 -Xlint:varargs
および注釈@SafeVarargs
と@SuppressWarnings({"unchecked", "varargs"})
が導入されています。 try
-with-resources文 - try
-with-resources文は、1つ以上のリソースを宣言するtry
文です。 リソースは、プログラムでの使用が終わったら閉じられなければならないオブジェクトです。 try
-with-resources文は、文の終わりで各リソースが確実に閉じられるようにします。 新しいjava.lang.AutoCloseable
インタフェースまたはjava.io.Closeable
インタフェースを実装しているオブジェクトは、リソースとして使用できます。 クラスjava.io.InputStream
、OutputStream
、Reader
、Writer
、java.sql.Connection
、Statement
、およびResultSet
は、AutoCloseable
インタフェースを実装するように改良され、すべてtry
-with-resources文でリソースとして使用できるようになりました。 catch
ブロックで複数の例外タイプを処理できます。 また、コンパイラでは、再スローされる例外について以前のリリースのJava SEよりも正確な分析が実行されます。 これにより、メソッド宣言のthrows
節に、より具体的な例外型を指定できます。 for
ループ - この新しい言語構造体により、コレクションや配列を反復する際の、イテレータおよびインデックス変数の煩雑さやエラー発生の可能性がなくなりました。 (JSR 201) @Deprecated
ノートを使用すると、プログラムの要素を非推奨にできます。 「いつ、どのようにAPIを非推奨とするか」を参照してください。