問題タブ [ecj]

私は新しい Eclipse Neon で作業しており、コードの一部ですぐにエラーが発生し始めました。
これは最初は奇妙に思えましたが、ここで Neon ECJ (Eclipse Java Compiler) が JDK 9 初期リリース コンパイラの姿勢を採用していることに気付きました。
そのリンクにあるのと同じ問題は発生しませんが、ここで説明する別の問題が発生します。

フィールドとしてのラムダ式宣言に関する問題

これは、Eclipse Neon、JDK 9コンパイラ、および JDK 8 コンパイラ (Eclipse の以前のバージョンではありません) でコンパイル エラーが発生するテスト クラスです。

上記のコードの場合、4 行目のエラーは次のsuffixとおりです。

宣言の前にsuffixフィールド宣言を移動すると、同じクラスで何が起こるかを見てみましょう。 addSuffix

上記のコードの場合、6 行目のエラーは次のsuffixとおりです。

          Java 9 はこのように動作する必要がありますか?

これは JDK 8 では問題なく機能しました。突然強制するのは奇妙なことのようです。特に、最終フィールドが正しくインスタンス化されていることを確認するためのコンパイル時のチェックが既に行われていることを考慮してください。
したがって、関数addSuffixがアクセスされるまでに、値が所定の位置にある必要がありますsuffix (nullそうでない場合は別の話です)。

また、JDK9 および ECJ で正常にコンパイルされる次のコードを試したことにも注意してください。

JDK 9 では、匿名クラス宣言と Lambda 式の間に大きな違いがあるようです。したがって、コンパイラ エラーが発生した場合、少なくとも ECJ は JDK 9 コンパイラを正確に模倣しています。

ストリームとジェネリックの問題

コード内の Generic が示すものとは異なる方法でコンパイラがこれを解釈する理由が思いつかないため、これには本当に驚きました。

このコードでは、次のエラーが発生します。

この情報に照らして、この場合、JDK 9 を適切に模倣していないことは ECJ に問題があり、単なる Eclipse のバグであることがわかります。

問題のセットアップは、3 つの Java ライブラリで構成されています (読みやすくするためにすべてのパッケージ名を削除しました。すべての場所で完全修飾名が使用されています)。

1. external-lib: 抽象クラスを提供します

   /li>

2. my-lib-A: クラスを提供します

   external-libmy-lib-A のクラスパスにあります。

3. my-lib-B は ClassA から FOO を静的にインポートします。

   my-lib-Amy-lib-B のクラスパスにありますが、external-libそうではありません。

問題: このimport static行で次のエラーが発生します。

The type AbstractExternal cannot be resolved. It is indirectly referenced from required .class files.

ただし(1)、ClassBを変更する場合

コンパイラは満足しています。

ただし (2)、2 つ目の抽象化を追加する場合、my-lib-A のように 2 つ

と

上記の例の ClassA.FOO の静的インポートは機能します。

質問 1: なぜ動作中にimport static ClassA.FOO失敗するのですか?import ClassAClassA.FOO

import static ClassA.FOO質問 2: my-lib-A から別のクラスを拡張してから AbstractExternal を拡張すると、なぜ機能するのですか?

編集: 重要な情報: 問題のコンパイラはEclipse Compiler for Java (ECJ) です。

編集 2: javac は ECJ と同期しており、静的インポートが失敗している間、ClassB で通常のインポートとクラス アクセスをコンパイルできます。