2013-02-24 5 views
6

Guava TypeTokenクラスを使用して、任意のタイプのインスタンスを他のタイプのオブジェクトに割り当てることができるかどうかをテストしています。GuavaのTypeToken.isAssignableFromメソッドの理解

次のコードスニペットではListとして宣言された型がList<String>からアサインされている場合は、私がテストしていて、その逆:?

TypeToken rawListType = new TypeToken<List>(){}; 
TypeToken parameterizedListType = new TypeToken<List<String>>(){}; 
System.out.println(rawListType.isAssignableFrom(parameterizedListType)); //true 
System.out.println(parameterizedListType.isAssignableFrom(rawListType)); //false 

isAssignableFrom戻りfalseになぜ2回目の呼び出し、以下のコードをコンパイルしていること与えられましたので、私は(警告付き)ListからList<String>を割り当てることができます?

List l = null; 
List<String> l2 = null; 
l = l2; 
l2 = l; //Type Safety Warning 

私の直感は、グアバがインあれば答えているということですこれらのタイプの尺度は、警告なしで割り当てることができます(?)。それが正しい場合は、代入可能性をコンパイラの意味でチェックすると、2番目のコードスニペットに表示されているように、別のオブジェクトに(警告の有無にかかわらず)割り当てることができます。

答えて

3

あなたが言ったように、コンパイラは汎用型を生の型から割り当てることができますが、それは割り当て可能性を意味するものではありません。コンパイラは、暗黙的なチェックされていないキャストを実行しています(したがって、警告)。

対応する未加工タイプの割り当て可能性をチェックしたいので、TypeToken.getRawTypeを使用してClass.isAssignableFromを使用します。

EDIT:あなたが指摘したように、この方法論はList<Integer>と相互に及びから割り当て可能List<String>をカウントします。これを回避するには、より一般化されたソリューションが必要だと思います。

この解決方法では配列型は考慮されません。

+0

hi @Paul。それは私が探しているものではなく、生の型の割り当て可能性をチェックすれば、リストはリストなどから割り当て可能であり、これは正しくありません。 コンパイラが暗黙のキャストを呪文の後ろに追加しなければならない場合でも、私は割り当て可能性を検証する方法を探しています。 – Sergio

+0

わかりました - 私の更新を見てください。 –

+0

あなたの解決策は私には正しいようですが、なぜTypeTokenはこれをしないのですか?少なくとも、彼らはjavadocの方法で私が思うように文書化しておくべきです。 – Sergio

関連する問題