自明ではない一般的な問題と可能な解決策

みなさんこんにちは！ 少なくとも少しのJavaを知っているプログラマーなら誰でも、ジェネリックのようなものを扱っていました。 この機能はJavaの5番目のバージョンですでに登場しました。今日、私が遭遇したジェネリック型に関連するいくつかの重要な問題、およびそれらが発生する理由と解決方法についてお話ししたいと思います。 この記事では、すべての（非）お気に入りのHibernateとSpringも取り上げます。



しかし、Javaの世界の新人が必ずしも理解していないジェネリックの複雑さのいくつかを説明することから始めます。 経験豊富な開発者の場合、最初の2つのポイントを読むことはできません。



1）ワイルドカード、拡張、スーパーが必要な理由



ワイルドカード（？）は、ジェネリッククラスに置き換えるときに使用されます。 つまり、パラメーター化された型が何であるかは関係ありません。また、ワイルドカードをsuperキーワードとextendキーワードと組み合わせて使用​​する場合、パラメーター化された型が親であるか特定のクラスを拡張することが重要です。 これが実際にどのように使用されているかの明確な例を示します。

public void foobar(Map<String, Object> ms) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Map <String、Number>型の変数をメソッドに渡したい場合、何もうまくいきません（理由-次の段落で説明します）が、メソッドがこのように宣言されていれば成功します。

 public void foobar(Map<String, ?> ms) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、2番目のケースでは、マップに値がどのタイプにあるかは問題ではないという事実について話しています。 しかし、これも制限を課します。マップ値でのみObjectクラスのメソッドを呼び出すことができます。 クラスNumberのオブジェクトのみがこのマップの値になり得ることがわかっている場合、このようにメソッドのシグネチャを書き換えることができます。

 public void foobar(Map<String, ? extends Number> ms) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Map値について、Numberクラスのメソッドを使用できます。 疑問が生じますが、なぜキーワードsuperが必要なのですか？ パラメーター化された型は特定のクラスの親になると言われていますが、これはポリモーフィズムを許可しません-すべてのクラスを除くすべてのクラスのメソッドを呼び出す-オブジェクト。 もう一度例を挙げます。

 List<? extends Number> list = new ArrayList<Number>(); List<? extends Number> list = new ArrayList<Integer>(); List<? extends Number> list = new ArrayList<Double>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IntegerとDoubleの両方がNumberから継承されるため、3つの宣言はすべて有効です。 3つのいずれの場合でも、リストからNumberから参照型の変数を取得し、このクラスのメソッドを呼び出すことができます。 もう1つは、最初のケースでは、このリンクにNumberとその相続人、2番目のInegerとその相続人、3番目のDoubleとその相続人が含まれることです。 そして今、あなたはこの宣言でリストに何を書くことができると思いますか？ あなたが答えた場合-数とその相続人、あなたは間違っていました。 答えは何もない！ この理由は、そのように宣言されたシートは、実際にはNumberシートまたはInteger、Doubleシート、およびNumberの子孫のいずれかである可能性があるためです。 superキーワードを使用して状況を考慮してください。

 List<? super Integer> list = new ArrayList<Integer>(); List<? super Integer> list = new ArrayList<Number>(); List<? super Integer> list = new ArrayList<Object>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような状況では、すべてが正反対です。 型キャストを行わない場合、シートからの値はObject型の参照変数にのみ割り当てることができますが、シートへの書き込みはInteger型のすべての子孫で利用できます。



2）

  リスト<番号>リスト=新しいArrayList <整数>（）。 

いや？ なぜ？！



時々、特にサードパーティのライブラリを使用している場合（これはJasperReportsライブラリでよく起こりました）、私の手がそのような割り当てを行うのに苦労します。 そして、コンパイラがこれを収集することを拒否すると、正しいrightりがすぐに高まります。 問題は何ですか？ なんで？ ポリモーフィズム？ 結局のところ、実際に問題は何ですか？ 整数ワークシートは、数値シートへの参照変数に書き込まれ、整数は数値型の直接の子孫であり、そのすべてのメソッドにアクセスできます。したがって、コレクションから要素を受け取っても問題はありません。 しかし、それらは発生します。スーパーキーワードについて注意深く読んだ場合、その理由をすでに理解しているはずです。

一番下の行は、数値シートと整数シートがまだ異なるオブジェクトであることです。 Numberシートは、Number（したがってDouble、Floatなど）を書き込むことを意味します。もちろん、Integerシートはこれを行うべきではありません。



しかし、彼らが言うように、あなたが本当に望むなら、あなたはあなたができないことをすることができます！

 List<Number> list = (List)new ArrayList<Integer>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、元のシートのタイプに関する情報を消去するだけで、いわゆる「生」タイプのクラスを受け取りました。これは、すでに何にでも割り当てることができます。 このようなトリックを行うことはお勧めできません。



3）GenericとSpring（または、インターフェースを消去する必要がある理由！）



最も興味深いものに到達しました。 この問題は、ジェネリック型に直接関係するものではありませんが、それらが開くスタイルが原因です。 いくつかのクラスを検討してください。

 @MappedSuperclass public abstract class BaseLinkEntity<S extends BaseEntity, T extends BaseEntity> extends BaseAuditableEntity { @JoinColumn(name = "SOURCE_ID", nullable = false) @ManyToOne(fetch = FetchType.LAZY) @JsonInclude(JsonInclude.Include.NON_EMPTY) protected S source; @JoinColumn(name = "TARGET_ID", nullable = false) @ManyToOne(fetch = FetchType.LAZY) @JsonInclude(JsonInclude.Include.NON_EMPTY) protected T target; } public interface LinkService<L extends BaseLinkEntity>{ List<L> getAllBySourceId(UUID id); List<L> getAllByTargetId(UUID id); } public abstract class BaseLinkService<L extends BaseLinkEntity> implements LinkReportService<L> { protected BaseLinkRepository<L> linkRepository; @Required public void setLinkRepository(BaseLinkRepository<L> linkRepository) { this.linkRepository = linkRepository; } @Override @Transactional(readOnly = true) public List<L> getAllBySourceId(UUID id) { return linkRepository.findBySourceId(id); } @Override @Transactional(readOnly = true) public List<L> getAllByTargetId(UUID id) { return linkRepository.findByTargetId(id); } } public class CardLinkServiceImpl extends BaseLinkReportService<CardLink> { @Override @Autowired @Qualifier("cardLinkReportRepository") public void setLinkRepository(BaseLinkRepository<CardLink> linkRepository) { super.setLinkRepository(linkRepository); } } public class MyClass{ @Autowired private LinkService<CardLink> cardLinkServiceImpl; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほぼ標準のスプリングアプローチ（中間ベースクラスを除く）は、インターフェイス実装バンドルです。 これは、エンティティが多対多の関係で接続されているデータベース内のテーブルを操作するために作成されました。 そして、すべてがうまくいくようです。 しかし、ここでは、CardLinkServiceImplでこれらのリンクの特定のメソッドをいくつか修正する必要がありました。 中間インターフェイスを作成しないために、最初にそれらを直接CardLinkServiceImplに追加し、適切な場所のクラスでそれを消去することにしました。 結論：コンテナ内のビンが見つかりませんでした。



インターネット上で少し調べたところ、この動作の理由が見つかりました。 まず、Spring 3はクラスをジェネリックでラップする方法を知りませんが、プロジェクトではSpring 4thバージョンが使用されました。 2番目の理由は、春には、コンテナにスローするクラスのプロキシが作成されることが多いためです。



SpringはAOPを使用します-多くの場所でアスペクト指向プログラミング このアプローチでは、一部のロジックはメソッドに直接実装されていませんが、春にaopのツールを使用してハングアップします。 このアプローチを低レベルで実装するため、ランタイムのスプリングはクラスのバイトコードを変更し、必要なロジックをクラスに追加し、元のオブジェクトに関する情報を消去するプロキシオブジェクトを作成しますが、そのインターフェイスに関する情報は残ります。



この場合、ここでaopを使用してトランザクションを管理します（@Transactionalアノテーション）。 その結果、特定のメソッドを別のインターフェイスに転送して、すでに消去する必要がありました。



4）汎用およびHibernate 5.2.1



そして今、問題はHibernateにあります。これは3番目の段落で説明したものと似ていますが、バグのように見えます。 コードのビット：

 public class Card{ @JoinColumn(name = "KIND_ID") @ManyToOne(fetch = FetchType.LAZY) protected DocumentKind documentKind; //  BaseEntity,     Id } public class CardLink extends BaseLinkEntity<Card, Card>{ } @NoRepositoryBean public interface BaseLinkRepository<T extends BaseLinkEntity> extends JpaRepository<T, UUID>, JpaSpecificationExecutor<T> { Page<T> findBySourceId(UUID sourceId, Pageable pageRequest); Page<T> findByTargetId(UUID targetId, Pageable pageRequest); } public interface CardLinkReportRepository extends BaseLinkRepository<CardLink>{ List<CardLink> findByTargetDocumentKindId(UUID documentKindId); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

hibernateはdocumentKindプロパティを見つけることができないため、SpringはCardLinkReportRepositoryの実装を作成できません。 実際、彼は間違ったオブジェクトで彼を探します。 何が何であるかを理解するために、私は長い間デバッグし、休止状態のソースコードを調べなければなりませんでした。 一般化された型を操作する機能が組み込まれていることがわかりますが、何らかの形で曲がって実装されました。 本質を簡単に説明しようとしますが、よりよく理解するには、MetamodelImplクラスを自分で探索できます（buildMetamodelメソッド（Iterator persistentClasses、Set mappedSuperclasses、SessionFactoryImplementor sessionFactory、boolean ignoreUnsuppentententonclass（パースペクティブ）、persistentContextClass、Persistentcontext、Persistent、ClassContext、 AttributeFactory（buildAttributeメソッド（AbstractManagedType ownerType、Propertyプロパティ））。



メタモデルを構築するとき、Hibernateは最初にすべてのクラスをそこに構築し（buildEntity）、その後でメソッドmethod-buildAttributeのエンティティに属性を書き込みます（クラスのアナロジー-フィールド）。 実際、BaseLinkEntityオブジェクトのメタモデルのエンティティは単一のインスタンスで作成され、特定のタイプの属性（ジェネリックフィールド）はbuildAttributeメソッドで1回だけ定義されます。 次に、リポジトリのJPAメソッドがdocumentKindフィールドを検索するときに、属性の構築時に挿入されたクラス内のフィールドを検索します。 型自体は、私がもはや理解することができなかったコンテキスト（どこで、どの時点で作成されるか）から取得されます。 そのため、BaseLinkEntityフィールドで検索できますが、特定のジェネリックタイプでは、アプリケーションのセット全体から1つのエンティティのみを検索できます。

最も興味深い（そして今のところ私には理解できない）ことは、この方法で書き直せば、すべてが機能することです。

 @Query("SELECT link FROM CardLink link WHERE link.target.documentKind.id = ?1") public interface CardLinkReportRepository extends BaseLinkRepository<CardLink>{ List<CardLink> findByTargetDocumentKindId(UUID documentKindId); }