23

私は 1 つのプロジェクトで Java 7 を試しており、この種の注釈プロセッサ (Bindgen および Hibernate JPA modelgen) から警告を受けています。

warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7'

@SupportedSourceVersion(SourceVersion.RELEASE_6)これは、アノテーション プロセッサ クラスのアノテーションが原因です。これらは Java 6 でコンパイルされているため、SourceVersion利用可能なの最大値は ですRELEASE_6。の Java 7 バージョンでは、 がSourceVersion導入されてRELEASE_7います。

私の質問: 注釈プロセッサはどのように前方互換性を処理することになっていますか? それらの個別の jdk6 および jdk7 バイナリ バージョンが必要ですか? ここで何か他のことを理解していませんか？

この懸念に関して、次の情報しか見つかりませんでした。

使用したQuerdydslバグレポート

@Override
public SourceVersion getSupportedSourceVersion() {
    return SourceVersion.latest();
}

コメンターが最新のソース バージョンのサポートを推奨しているOracle ブログ

4

1 に答える 1

16

前方互換性は、 ElementVisitor.visitUnknownを実装するなど、未知の言語構造を適切に処理することによって処理されます。

上記のOracle ブログには別のエントリがあり、前方互換性に関する 2 つのポリシーを提案しています。

  • 現在の言語バージョンでのみ動作するようにプロセッサを作成します。
  • 未知の将来の構造に対処するプロセッサを作成します。

SourceVersion.latest()2つ目は、質問にすでに投稿されているように戻ることによって行われます。

追加の言語要素によって何も壊れないことが確実な場合は、ほとんどの場合、これを行っても問題ないと思います。もちろん、新しいバージョンでもすべて問題ないと仮定するだけでなく、テストも行う必要があります。

わかりました、未知の言語構造を適切に処理することは、少しあいまいに聞こえると思います。そのため、いくつかの例を次に示します。

既知の言語コンストラクト (クラスのアノテーションなど) のカスタム タイプのアノテーションをチェックし、見つかったものの簡単なドキュメントを作成するプロセッサがあるとします。新しいバージョンでも動作すると考えて間違いないでしょう。私の意見では、特定のバージョンに制限することは良い決定ではありません。

見つけられるすべての要素をチェックし、コード構造を分析してそこからグラフを生成するプロセッサがあるとします。新しいバージョンでは問題が発生する場合があります。(グラフに未知のノードを追加するなどして) 何らかの形で未知の言語構造を処理できる場合がありますが、これは、それが理にかなっていて、問題を解決する価値がある場合にのみ行ってください。プロセッサが未知のものに直面したときに役に立たない場合は、おそらく特定の Java バージョンに固執する必要があります。

使用されるポリシーに関係なく、私の意見では、言語に対する今後の変更を監視し、それに応じてプロセッサを更新することが最善の方法です。たとえば、Java 7 では、プロジェクト コインによっていくつかの新しい言語機能が導入されましたが、これらはおそらくプロセッサからは見えません。一方、Java 8 には、型注釈など、処理に影響を与える新しい構成要素があります。ただし、新しい言語機能はそれほど頻繁には発生しないため、長い間何も変更する必要さえない可能性があります。

于 2011-11-18T20:44:24.127 に答える