Re: Obtaining class instance of generic quantified type
On Apr 24, 12:26 pm, Rakesh <rakesh.use...@gmail.com> wrote:
On Apr 24, 1:07 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
On Apr 24, 12:13 pm, Rakesh <rakesh.use...@gmail.com> wrote:
Hi -
For a particular method with a signature like this -
class GlobalClass {
public abstract <R> R process(Object obj_, Class<R>
returnType_);
}
I wanted to quantify it with NodeList<Node> .(substitute R with
NodeList<Node> ).
So I tried this one ..
GlobalClass global = ...
Object obj =
NodeList<Node> list = global.process(obj, NodeList.class );
That code resulted in warnings.
Doing something like -
NodeList<Node> list = global.proces(obj,
NodeList.class<Node.class> );
results in a compilation error.
What is the correct way of doing this.
There is no object reprepsenting the class NodeList<Node> - only an
object representing the class NodeList. This is one of the many holes
in generics as a consequence of erasure. By the same token, you
cannot reflectively create a NodeList<T> for any T - you can only
create instances of the raw type, NodeList.
In short, you can't get there from here without even more code,
without ignoring Java's type safety rules somewhere.
Got it - There seems to be a case for reified generics here -http://tech.puredanger.com/java7#reified.
Anybody aware of how serious this suggestion is - and if this would
be implemented in Java 7 (as in the wishlist). As somebody else
pointed out in their blog - it is high time to erase 'erasure' .
On 24 Apr, 12:26, Rakesh <rakesh.use...@gmail.com> wrote:
On Apr 24, 1:07 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
On Apr 24, 12:13 pm, Rakesh <rakesh.use...@gmail.com> wrote:
Hi -
For a particular method with a signature like this -
class GlobalClass {
public abstract <R> R process(Object obj_, Class<R>
returnType_);
}
I wanted to quantify it with NodeList<Node> .(substitute R with
NodeList<Node> ).
So I tried this one ..
GlobalClass global = ...
Object obj =
NodeList<Node> list = global.process(obj, NodeList.class );
That code resulted in warnings.
Doing something like -
NodeList<Node> list = global.proces(obj,
NodeList.class<Node.class> );
results in a compilation error.
What is the correct way of doing this.
There is no object reprepsenting the class NodeList<Node> - only an
object representing the class NodeList. This is one of the many holes
in generics as a consequence of erasure. By the same token, you
cannot reflectively create a NodeList<T> for any T - you can only
create instances of the raw type, NodeList.
In short, you can't get there from here without even more code,
without ignoring Java's type safety rules somewhere.
Got it - There seems to be a case for reified generics here -http://tech.puredanger.com/java7#reified.
Anybody aware of how serious this suggestion is - and if this would
be implemented in Java 7 (as in the wishlist). As somebody else
pointed out in their blog - it is high time to erase 'erasure' .
People have definitely been looking into it but I don't get a strong
feeling that it's going to happen for Java 7. The main thing I don't
like about the proposals is that generics would not be reified by
default - you would need to add another keyword or some syntax to tell
the compiler and runtime to keep the type information. So interfaces
may require the reified type - they've discussed some nasty things to
retrofit collections to work in this case. I'm not sure the tradeoffs
at this point are worth it, even to erase erasure (to quote Weiqi
Gao).
Alex Miller
http://tech.puredanger.com