「ラムダ式から参照されるローカル変数は、finalまたは事実上のfinalである必要があります」というエラー

Question

下記質問の続きです。中途半端してしまったので、改めて質問します。
https://teratail.com/questions/42539

Javaでラムダ式からローカル変数を参照すると、タイトルのようなエラーとなりますが、finalな配列（オブジェクト）として参照させれば、エラーとはなりません。
実際IDEなどで、ラムダ式からローカル変数を参照ような実装をすると「B」のようなサジェストをされます。
ですが、決して見栄えの良い書き方とはいえません。
であれば、コンパイラが内部的にこのように変更してくれればよいような気もするのですが、どうでしょうか。
また、将来的にそんな変更がありえるものでしょうか。

---

A.ラムダを使わない記述

List<String> list = Arrays.asList("hoge", "fuga");
int a = 0;
for(String elem : list){
    if(elem.startsWith("h")){
        a++;
    }
}

---

B.ラムダを使って配列（オブジェクト）経由で参照させる記述

List<String> list = Arrays.asList("hoge", "fuga");
final int[] a = {0};
list.stream().filter(elem -> elem.startsWith("h")).forEach(elem -> a[0]++);

Answer 1

例に出されてるコードですとcount()使えば良いじゃんで終わってしまうかと思いますので、課題を次のように変更しました。

• 下記の要件を満たすメソッドを作成する。
• 文字列(String)のリスト(List)を引数として受け取る。
• リストの各要素で"h"から始まる文字列の数をカウントして、その数(Long)を返す。
• リストの各要素で"h"から始める文字列は、先頭の"h"を削除した文字列に置き換える(リスト自身を変更)。

で、作ったのが下記です。

import java.util.AbstractMap.SimpleImmutableEntry;
import java.util.Collections;
import java.util.List;
import java.util.Arrays;
import java.util.Iterator;
import java.util.function.BiFunction;
import java.util.function.Consumer;
import java.util.function.Function;
import java.util.stream.Collectors;
import java.util.stream.Stream;
public class LambdaTest {
  public static void main(String[] args) {
    final Consumer<Function<List<String>, Long>> cons = (func) -> {
      final List<String> list = Arrays.asList("hoge", "fuga");
      final Long count = func.apply(list);
      System.out.println(count);
      list.forEach((str) -> System.out.println(str));
    };
    cons.accept(LambdaTest::checkAndDelFor);
    cons.accept(LambdaTest::checkAndDelSeparate);
    cons.accept(LambdaTest::checkAndDelOnce);
  }

  public static Long checkAndDelFor(List<String> list) {
    long count = 0;
    for (int i = 0; i < list.size(); i++) {
      if (list.get(i).startsWith("h")) {
        count++;
        list.set(i, list.get(i).substring(1));
      }
    }

    return count;
  }

  public static Long checkAndDelSeparate(List<String> list) {
    final long count =
        list.stream().filter((str) -> str.startsWith("h")).count();
    list.replaceAll((str) -> str.startsWith("h") ? str.substring(1) : str);

    return count;
  }

  public static Long checkAndDelOnce(List<String> list) {
    final SimpleImmutableEntry<Long, List<String>> result =
        list.stream().reduce(
            new SimpleImmutableEntry<Long, List<String>>(
                new Long(0), Collections.emptyList()),
            (acc, str)
                -> {
              final Long accCount = acc.getKey();
              final Stream<String> accStream = acc.getValue().stream();
              final BiFunction<Boolean, String,
                               SimpleImmutableEntry<Long, List<String>>>
                  createPair = (incr, s)
                  -> new SimpleImmutableEntry<Long, List<String>>(
                      incr ? accCount : accCount + 1,
                      Stream.concat(accStream, Stream.of(s))
                          .collect(Collectors.toList()));

              return str.startsWith("h")
                  ? createPair.apply(true, str.substring(1))
                  : createPair.apply(false, str);
            },
            (a, b)
                -> new SimpleImmutableEntry<Long, List<String>>(
                    a.getKey() + b.getKey(),
                    Stream.concat(a.getValue().stream(), b.getValue().stream())
                        .collect(Collectors.toList()))

                );
    final Iterator<String> itr = result.getValue().iterator();
    list.replaceAll((_s) -> itr.next());

    return result.getKey();
  }
}

checkAndDelForが愚直なforループです。説明は不要で良いですよね。

checkAndDelSeparateはカウントと置き換えを別々にしたものです。とても短く単純ですが、"h"から始まるというチェックが一つの要素に付き二回走るという無駄があり、なんともすっきりしたものとは言えません。

と言うことで、最後のcheckAndDelOnce は"h"から始まるというチェックをなんとうか一回にしようと頑張った物です。

そもそもの考えとして、Java8のラムダ式はStream等で使うことを想定しているかと思います。そして、ラムダ式を含むこれらの処理は関数型プログラミングの考えを基にしており、関数型プログラミングでは基本的にオブジェクトは全てimmutableとして扱うべき、副作用が無い純粋関数を使うべきとしています。また、Streamは並列化が容易にできることを想定している側面があり、各ラムダ式が純粋関数でない場合は、並列化がうまく動作するかが保証できなくなります。つまり、「オブジェクトを変更する等の副作用がある処理をすること自体がラムダ式の使い方として間違っている」と私は個人的に思っています。

その考えを基に最終的にできが上がったのがcheckAndDelOnce です。ソースは一番長いですが、考え方は単純です。reduceを使いながら、カウントと新しいリストを次々作って言っているだけで、最後に元々のリストの中身をできあがったリストに置き換えています。でも、何か複雑なことをしているように見えのも事実です。なぜそうなったのか…それはJavaの関数型プログラミング対応が中途半端だからです。

Java8からラムダ式やStream、Optional等関数型プログラミングの要素が追加されました。しかし、タプルが無い、zipが無い、Streamはmutable、ラムダ式内での検査例外がすごく邪魔、::の使い方が他の言語と違う、プリミティブ型Streamを作るしか無かったという事情、オブジェクト自体を変更させていくという命令型オブジェクト指向の典型的なやり方に基づいた言語設計、等などの理由により、関数型プログラミングしやすいとはとてもじゃないですが言えません。

ということで、オブジェクト自体を変更させていくような命令型プログラミングでコーディングする場合は、そもそもラムダ式は使わない方がいいと思います。かといって、ラムダ式を使って関数型プログラミングをするのであれば、そもそもJavaは捨てた方が良いと個人的には思っています。

Comments

[mosa]

詳細にご説明いただきありがとうございます。
元々は、IntelliJ に final int[] a = {0}; というサジェストをされて、意味はわかるがなんという提案をしてくるんだ、と思い考えていることを質問させていただきました。
ちょっとまだ checkAndDelOnce は理解できていないですが、時間をかけて見てみます。
具体的に仕事上なにか困っている等の話ではないので、こういった考えをおきかせいただいて助かります。

Answer 2

内部的に変更してくれれば～と言いますが、intとint[]ではまるで違います。全く構造の違うものに「内部的に変更」してしまったら様々な危険が伴います。
それに、そのようなコードならリダクションを使って対応できます。特にこのコードは数えるだけなので、long型になりますがcountメソッドが使えます。単純に数えるのでないなら、それ用のリダクションを記述するreduceメソッドもあります。

Comments

[mosa]

ありがとうございます。
「様々な危険」について具体的な例などを１つ２つなどいただけますか。
元々は、IntelliJ に final int[] a = {0}; というサジェストをされて、意味はわかるがなんという提案をしてくるんだ、と思い考えていることを質問させていただきました。

Answer 3

将来的にそんな変更がありえるものでしょうか。

State of the Lambda

情報が古いですがopenjdkのlambda pojectのドキュメント(2013年)をみるとnon finalの変数が実質的にfinalかどうか推論するよという話の後に、以下のような記述があります。

However, it is not a goal of this project to address all the problems of inner classes. Neither arbitrary capture of mutable variables (4) nor nonlocal control flow (5) are within this project's scope (though such features may be revisited in a future iteration of the language.)

英語が得意じゃないので間違ってるかもですが「このプロジェクトでは変更可能な変数をlambdaの中で参照することをゴールとはしない。でも将来またこの点を検討することもあるかもね」というような意味と捉えました。3年前なので状況は変わっているかもしれませんが・・・可能性としてはなくはないといったところでしょうか。

C#では質問者さんがいったような考え方（配列ではなくてlambdaのためにコンパイラーが自動生成する無名クラスのフィールドとして）サポートしているようで、ローカル変数への代入が無名クラス(的なもの)のフィールドの代入に置き換わるように見えました。javaのlambdaの実装も似た雰囲気なので同様の方式はとれると思います。

この仕様は実装の手間もさりながらJavaのポリシーにあうのかどうかも争われる気がします。

Comments

[mosa]

ありがとうございます。
元々は、IntelliJ に final int[] a = {0}; というサジェストをされて、意味はわかるがなんという提案をしてくるんだ、と思い考えていることを質問させていただきました。
頂いたドキュメントを元にまた情報を探してみます。
また、今は環境がないのですが、 C#でどういった記述になるのかもみてみたいと思います。

[KSwordOfHaste]

「なんという提案をしてくるんだ」＝＞同感です。

Answer 4

「自動でプリミティブ型の変数を置き換える」ことでは対応できないものが1つあります。引数です。引数は外部にインターフェースとして公開される以上、内部の論理だけで勝手に置き換えてしまうことはできません。

そして、あくまで個人的な感覚かもしれませんが、「同じint i;で宣言したものが状況によってプリミティブ型の変数になったり、配列やオブジェクトのフィールドになったりする」という一貫性のなさのほうが、Java的には「インナークラスやラムダの内部で直接プリミティブ型変数を書き換えられない」という利便性より問題があるのかなと思います。

Javaは利便性より厳密性に重きをおいた言語です。JVMで動く言語は他にもありますので、Javaの思想が気に入らないなら別なものに乗り換えるのもありです（Javaのエコシステムは、他のJVM言語でもほぼそのまま使えます）。

Comments

[mosa]

ありがとうございます。
確かに引数では無理ですね。
元々は、IntelliJ に final int[] a = {0}; というサジェストをされて、意味はわかるがなんという提案をしてくるんだ、と思い考えていることを質問させていただきました。
おっしゃるとおりだとすると、このサジェストは「あまり適切ではないけど、どうしてもこの場でローカル変数を書き換えたければこうするしかないよ」という程度のものという感じですね。