ラムダ式を使用してstream（）。map（…）をデバッグする方法は？

私たちのプロジェクトでは、Java 8に移行し、その新機能をテストしています。

私のプロジェクトでは、Guava述語と関数を使用してCollections2.transform、およびを使用して一部のコレクションをフィルター処理および変換していCollections2.filterます。

この移行では、たとえばguavaコードをjava 8に変更する必要があります。つまり、私が行っている変更は次のようなものです。

List<Integer> naturals = Lists.newArrayList(1,2,3,4,5,6,7,8,9,10,11,12,13);

Function <Integer, Integer> duplicate = new Function<Integer, Integer>(){
    @Override
    public Integer apply(Integer n)
    {
        return n * 2;
    }
};

Collection result = Collections2.transform(naturals, duplicate);

に...

List<Integer> result2 = naturals.stream()
    .map(n -> n * 2)
    .collect(Collectors.toList());

グアバを使用して、各変換プロセスをデバッグできたので、コードのデバッグは非常に快適でしたが、たとえば、デバッグ方法が心配です.map(n -> n*2)。

デバッガーを使用すると、次のようなコードが表示されます。

@Hidden
@DontInline
/** Interpretively invoke this form on the given arguments. */
Object interpretWithArguments(Object... argumentValues) throws Throwable {
    if (TRACE_INTERPRETER)
        return interpretWithArgumentsTracing(argumentValues);
    checkInvocationCounter();
    assert(arityCheck(argumentValues));
    Object[] values = Arrays.copyOf(argumentValues, names.length);
    for (int i = argumentValues.length; i < values.length; i++) {
        values[i] = interpretName(names[i], values);
    }
    return (result < 0) ? null : values[result];
}

しかし、コードをデバッグするのはGuavaほど簡単ではありませんn * 2。実際、変換を見つけることができませんでした。

この変換を確認する方法またはこのコードを簡単にデバッグする方法はありますか？

編集：私はさまざまなコメントと投稿された回答から回答を追加しました

Holger私の質問に答えたコメントのおかげで、ラムダブロックを使用するアプローチにより、変換プロセスを確認し、ラムダ本体内で何が起こったかをデバッグすることができました。

.map(
    n -> {
        Integer nr = n * 2;
        return nr;
    }
)

Stuart Marksメソッド参照を持つというアプローチのおかげで、変換プロセスをデバッグすることもできました。

static int timesTwo(int n) {
    Integer result = n * 2;
    return result;
}
...
List<Integer> result2 = naturals.stream()
    .map(Java8Test::timesTwo)
    .collect(Collectors.toList());
...

Marlon Bernardes回答のおかげで、私のEclipseには何が必要かが表示されず、peek（）の使用が結果の表示に役立ちました。

私は通常、EclipseまたはIntelliJ IDEAを使用しているときは、ラムダ式のデバッグに問題はありません。ブレークポイントを設定し、ラムダ式全体を検査しないようにしてください（ラムダ本体のみを検査します）。

もう1つの方法は、を使用peekしてストリームの要素を検査することです。

List<Integer> naturals = Arrays.asList(1,2,3,4,5,6,7,8,9,10,11,12,13);
naturals.stream()
    .map(n -> n * 2)
    .peek(System.out::println)
    .collect(Collectors.toList());

更新：

mapは、intermediate operationつまり、terminal operationが実行された後にのみ実行される遅延操作であるため、混乱していると思います。したがってstream.map(n -> n * 2)、ラムダボディを呼び出すと、現時点では実行されていません。端末操作が呼び出された後（collectこの場合は）、ブレークポイントを設定して検査する必要があります。

詳細については、ストリーム操作を確認してください。

更新2：

Holgerのコメントを引用：

ここで注意が必要なのは、mapへの呼び出しとラムダ式が1行にあるため、行ブレークポイントが2つのまったく関係のないアクションで停止することです。

直後に改行を挿入するmap( と、ラムダ式にのみブレークポイントを設定できます。また、デバッガーがreturnステートメントの中間値を表示しないことも珍しくありません。ラムダをに変更すると、n -> { int result=n * 2; return result; } 結果を検査できます。繰り返しますが、行ごとにステップするときに改行を適切に挿入します…

IntelliJには、Javaストリームデバッガプラグインなど、このケースに最適なプラグインがあります。あなたはそれをチェックアウトする必要があります：https : //plugins.jetbrains.com/plugin/9696-java-stream-debugger?platform=hootsuite

IDEAデバッガーツールウィンドウを拡張するには、[現在のストリームチェーンのトレース]ボタンを追加します。このボタンは、デバッガーがストリームAPI呼び出しのチェーンの内部で停止したときにアクティブになります。

個別のストリーム操作を操作するための優れたインターフェースがあり、デバッグする必要があるいくつかの値を追跡する機会が与えられます。

ここをクリックして、デバッグウィンドウから手動で起動できます。

ラムダのデバッグは、NetBeansでもうまく機能します。NetBeans 8とJDK 8u5を使用しています。

ラムダがある行にブレークポイントを設定すると、実際には、パイプラインが設定されたときに1回、次に各ストリーム要素に対して1回ヒットします。この例を使用すると、ブレークポイントに初めて到達したときにmap()、ストリームパイプラインを設定する呼び出しになります。

main期待どおりに、コールスタックとローカル変数およびパラメーター値を確認できます。ステップ実行を続けると、「同じ」ブレークポイントが再度ヒットしますが、今回はラムダの呼び出し内にあります。

今回は、コールスタックがストリームメカニカル内の深い場所にあり、ローカル変数はラムダ自体のローカルであり、囲んでいるmainメソッドではないことに注意してください。（naturalsこれを明確にするために、リストの値を変更しました。）

以下のようマーロンBernardesは、（1）を指摘し、あなたが使用することができpeek、彼らはパイプラインのことで行くような値を検査します。ただし、これを並列ストリームから使用する場合は注意してください。値は、異なるスレッド間で予測できない順序で出力される可能性があります。からデバッグデータ構造に値を格納する場合peek、そのデータ構造はもちろんスレッドセーフでなければなりません。

最後に、ラムダ（特に複数行のステートメントラムダ）の多くのデバッグを行っている場合は、ラムダを名前付きメソッドに抽出し、メソッド参照を使用して参照することをお勧めします。例えば、

static int timesTwo(int n) {
    return n * 2;
}

public static void main(String[] args) {
    List<Integer> naturals = Arrays.asList(3247,92837,123);
    List<Integer> result =
        naturals.stream()
            .map(DebugLambda::timesTwo)
            .collect(toList());
}

これにより、デバッグ中に何が起こっているかを簡単に確認できます。さらに、この方法でメソッドを抽出すると、単体テストが簡単になります。ラムダが非常に複雑なので、シングルステップで実行する必要がある場合は、とにかくラムダの一連の単体テストが必要になるでしょう。

Intellij IDEA 15はそれをさらに簡単にするようで、ラムダがある行の一部で停止できます。最初の機能を参照してください：http : //blog.jetbrains.com/idea/2015/06/intellij-idea-15 -eap-is-open /

更新された詳細情報（2019年10月）を提供するためだけに、IntelliJは非常に便利なこのタイプのコードをデバッグするための非常に優れた統合を追加しました。

ラムダを含む行で停止するときにF7（ステップイン）を押すと、IntelliJはデバッグするスニペットを強調表示します。デバッグするチャンクを切り替えることができTabますF7。決定したら、もう一度クリックします。

ここにいくつかのスクリーンショットを示します：

1- F7（ステップイン）キーを押すと、ハイライト（または選択モード）が表示されます

2- Tab複数回使用してデバッグするスニペットを選択します

3- F7（ステップイン）キーを押してステップイン

IDEを使用したデバッグは常に役立ちますが、ストリーム内の各要素をデバッグする理想的な方法は、Java Steamが遅延評価されるため、ターミナルメソッド操作の前にpeek（）を使用することです。評価されません。

List<Integer> numFromZeroToTen = Arrays.asList(1,2,3,4,5,6,7,8,9,10);

    numFromZeroToTen.stream()
        .map(n -> n * 2)
        .peek(n -> System.out.println(n))
        .collect(Collectors.toList());