なぜJavaには具体化されたジェネリックがないことに気を付けるべきなのですか？

これは、候補者がJava言語に追加したいものとして、最近インタビューで尋ねた質問として浮上しました。Javaがジェネリックスを具体化していないことは、痛みとして一般的に認識されていますが、候補者がプッシュされたとき、候補者が実際に達成できたことを私に伝えることができませんでした。

当然、生の型はJava（および安全でないチェック）で許可されているため、ジェネリックを破壊しList<Integer>て（たとえば）実際にが含まれている可能性がありますString。タイプ情報を具体化すると、これは明らかに不可能になる可能性があります。しかし、これ以上のものがあるに違いありません！

人々が本当にやりたいことの例を投稿できますか？つまりList、実行時にaのタイプを取得できることは明らかですが、それを使用して何をしますか？

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

編集：これに対する迅速な更新は、回答が主にClassパラメータとして渡される必要性に関係しているように思われるためです（たとえばEnumSet.noneOf(TimeUnit.class)）。私はこれが不可能であるという線に沿って何かをもっと探していました。例えば：

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

私がこの「必要性」に出くわした数回から、最終的にはこの構成に要約されます。

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

これはデフォルトのコンストラクターTがあると仮定してC＃で機能します。でランタイムタイプtypeof(T)を取得し、でコンストラクタを取得することもできますType.GetConstructor()。

一般的なJavaソリューションはClass<T>、引数としてを渡すことです。

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

（メソッドの引数も問題ないため、必ずしもコンストラクタの引数として渡す必要はありません。上記は単なる例であり、try-catch簡潔にするために省略されています）

他のすべてのジェネリック型構成体の場合、実際の型はリフレクションを使用すると簡単に解決できます。以下のQ＆Aは、ユースケースと可能性を示しています。

• java.util.Listのジェネリック型を取得します
• 実行時にジェネリック型を取得するにはどうすればよいですか？
• 抽象スーパークラスのジェネリック型引数の実際の型を取得します

最も一般的に私に噛み付くのは、複数のジェネリック型にわたる複数のディスパッチを利用できないことです。次のことは不可能であり、それが最善の解決策となる多くの場合があります。

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

型の安全性が頭に浮かびます。パラメーター化された型へのダウンキャストは、具体化されたジェネリックなしでは常に安全ではありません。

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

また、抽象化のリークは少なくなります -少なくとも、型パラメーターに関する実行時情報に関心があるかもしれません。今日、ジェネリックパラメータの1つのタイプに関する実行時情報が必要な場合は、それも渡す必要がClassあります。このように、外部インターフェイスは実装に依存します（パラメーターについてRTTIを使用するかどうか）。

コードで一般的な配列を作成することができます。

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

これは古い質問です。答えは山ほどありますが、既存の答えはおかしいと思います。

「具体化された」とは、単に本物を意味し、通常は型消去の反対を意味します。

Java Genericsに関連する大きな問題：

• この恐ろしいボクシング要件と、プリミティブと参照タイプの間の接続解除。これは具体化や型消去とは直接関係ありません。C＃/ Scalaはこれを修正します。
• 自己型はありません。このため、JavaFX 8は「ビルダー」を削除する必要がありました。型消去とはまったく関係ありません。Scalaはこれを修正しますが、C＃については不明です。
• 宣言サイド型の差異はありません。C＃4.0 / Scalaにはこれがあります。型消去とはまったく関係ありません。
• オーバーロードすることはできませんvoid method(List<A> l)とmethod(List<B> l)。これは型の消去によるものですが、非常に小さなものです。
• ランタイム型リフレクションはサポートされていません。これが型消去の中心です。コンパイル時にできるだけ多くのプログラムロジックを検証および証明する超高度なコンパイラーが必要な場合は、リフレクションをできるだけ使用しないでください。このタイプの型消去は気になりません。もっとパッチ、スクリプト、動的型のプログラミングが好きで、コンパイラがロジックをできる限り正しく証明することをあまり気にしない場合は、リフレクションを改善し、型消去を修正することが重要です。

シリアライゼーションは具体化によってより簡単になります。私たちが望むのは

deserialize(thingy, List<Integer>.class);

私たちがしなければならないことは

deserialize(thing, new TypeReference<List<Integer>>(){});

醜く見えて、ファンキーに動作します。

次のようなことを言うと本当に役立つ場合もあります

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

これらの物は噛まないことが多いですが、起こると噛みます。

私のJava Geneircsへの露出は非常に限られており、他の回答がすでに言及している点とは別に、モーリスナフタリンとフィリップウォルダーの著書「Java Generics and Collections」で説明されているシナリオがあります。

タイプはreifiableではないので、パラメータ化された例外を持つことはできません。

たとえば、以下のフォームの宣言は無効です。

class ParametericException<T> extends Exception // compile error

これは、catch句が、スローされた例外が特定の型と一致するかどうかをチェックするためです。このチェックは、インスタンステストで実行されるチェックと同じです。また、タイプを変更できないため、上記の形式のステートメントは無効です。

上記のコードが有効であれば、以下の方法で例外処理が可能でした。

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

この本では、JavaジェネリックがC ++テンプレートの定義（拡張）と同様に定義されている場合、最適化の機会が増えるため、より効率的な実装につながる可能性があると述べています。しかし、これ以上の説明は提供しないので、知識のある人々からの説明（ポインタ）は役に立ちます。

配列は具体化された場合、おそらくジェネリックスではるかにうまく機能します。

イテレータとしてjdbc結果セットを提示するラッパーがあります（つまり、依存関係の注入により、データベースから発生した操作の単体テストをはるかに簡単に行うことができます）。

APIはIterator<T>、Tがコンストラクターで文字列のみを使用して構築できるいくつかの型であるように見えます。次に、イテレーターはsqlクエリから返された文字列を調べ、それをT型のコンストラクターと照合しようとします。

ジェネリックが実装されている現在の方法では、結果セットから作成するオブジェクトのクラスも渡す必要があります。私が正しく理解していれば、ジェネリックスが具体化されていれば、T.getClass（）を呼び出してそのコンストラクターを取得するだけでよく、Class.newInstance（）の結果をキャストする必要はありません。

基本的に、オブジェクトから多くのことを推論できるため、APIの作成が（アプリケーションを作成するだけでなく）簡単になると思います。これにより、必要な構成が少なくなります...アノテーションの影響は、それらがconfigの連の代わりにspringやxstreamのようなもので使用されているのを見ました。

プリミティブ（値）型のボックス化を回避することは、すばらしいことです。これは、他の人が提起した配列の不満にいくらか関係しており、メモリの使用が制限されている場合は、実際に大きな違いが生じる可能性があります。

パラメータ化されたタイプを反映できることが重要であるフレームワークを作成する場合、いくつかのタイプの問題もあります。もちろん、これは実行時にクラスオブジェクトを渡すことで回避できますが、これによりAPIが不明瞭になり、フレームワークのユーザーに追加の負担がかかります。

あなたが特別なことを成し遂げるということではありません。理解するのは簡単です。型の消去は初心者にとっては困難なことのように思われ、最終的にはコンパイラーの動作方法を理解する必要があります。

私の意見では、ジェネリックは単なる余分なキャストであり、冗長なキャストを大幅に削減します。

ここですべての回答が見落としていることの1つは、タイプが消去されるため、ジェネリックインターフェイスを2回継承できないためです。これは、きめの細かいインターフェースを作成するときに問題になる可能性があります。

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

これが今日私を捕まえたものです：具象化せずに、一般的なアイテムの可変引数リストを受け入れるメソッドを作成した場合...

それは起こりそうにないようです？...もちろん、データ型としてClassを使用するまでは... この時点で、呼び出し元は多くのClassオブジェクトを喜んで送信しますが、単純なタイプミスはTに準拠していないClassオブジェクトと災害ストライキを送信します。

（注：ここで間違えた可能性がありますが、「ジェネリック変数」についてグーグルで検索すると、上記は期待どおりのように見えます。これを実用的な問題にしているのはクラスの使用だと思います-呼び出し元は慎重に:(）

たとえば、Classオブジェクトをマップのキーとして使用するパラダイムを使用しています（単純なマップよりも複雑ですが、概念的にはそうなっています）。

たとえば、これはJava Genericsでうまく機能します（簡単な例）：

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

たとえば、Java Genericsで具体化しない場合、これはすべての「クラス」オブジェクトを受け入れます。そしてそれは前のコードのほんの小さな拡張です：

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

上記の方法は、個々のプロジェクトで何千回も書かれる必要があるため、人的ミスの可能性が高くなります。間違いのデバッグは「面白くない」ことを証明しています。私は現在、代替案を見つけようとしていますが、希望はあまりありません。