Re: [all] Generics and Return Type?
Hi James and Matt, and thank you for answering.
James' code is nice, and it is exactly what I was talking about. Anyway,
it covers one of the possible needs : the return type of a method; while
also parameters can be parametrized and in some situations (like a List)
simply knowing which type the programmer has assigned to a specified
generic declaration will be enough for reflection to work.
I suppose I will merge James' code, which is by far faster and cleaner
than mine, in my library. What I'd like to know is if there is space
for such a library somewhere here in Commons, and it seems like lang
could be interested. In that case, I will complete it and clean it up a
little and then contribute it to lang.
Simone
James Carman wrote:
Specifically, take a look at:
http://svn.apache.org/repos/asf/commons/proper/proxy/branches/version-2.0-work/src/main/java/org/apache/commons/proxy/invoker/recorder/InvocationRecorder.java
That's where I do my recording stuff. And, in there, I've got code
that resolves the return types of generified methods.
On Tue, Sep 23, 2008 at 4:25 PM, Matt Benson [EMAIL PROTECTED] wrote:
James later wrote some code to do this, which is in a
branch of Commons Proxy. I think we should add
something similar to the reflect subpackage (in trunk)
of the [lang] component, given the fact that BeanUtils
is in maintenance mode.
-Matt
--- Simone Gianni [EMAIL PROTECTED] wrote:
Hi all,
sorry for reopening such an old thread, but it's the
latest I've found
searching for generics.
As James say, it is quite a pain to determine types
in a generic class.
I think commons could be a good place for a library
that makes this
operation easier, maybe in beanutils since its
mission is to provide
easy-to-use wrappers around [these capabilities |
Reflection and
Introspection], and I'm writing such a library
(actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types,
like local variables,
it is still possible for subclasses explicitly
extending a generic type
with concrete types and for fields declared as non
generics to obtain
vital informations about the type of generic fields
and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the
People.add() method will
accept a Person, and the names.get() method will
return a String.
Unfortunately, it is quite complex to determine it,
cause Sun decided to
use only 4 interfaces, and force the user to make
continuous blind casts
between them.
JRE currently seems not to provide an alternative
simple solution, nor
using reflection nor introspection. Even worse,
given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends
GenericBeanPerson,
Introspection (and so BeanUtils) will return the
type of the myGeneric
property as java.lang.Object, but trying to set the
property to any
value which is not a Person will cause a
ClassCastException at runtime
because of explicit cast in bridging methods
(methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter
gets overridden in
a subclass: in that case the compiler requires that
the concrete type
is used, thus making the getters and setter appear
as having different
types, and causing problems both in Introspector and
BeanUtils.
I had this problem recently in my Apache Lab, and
wrote a (simple, not
yet complete nor optimized, but functioning) wrapper
around Class and
Method to obtain this informations. It works also in
obscure situations
where a generics is extended by a chain of classes
and determining the
actual type require recursion on superclasses while
remapping all
generic declarations from the concrete one up to
the generic one.
I don't think it is yet able to handle all possible
situations, but I
think it covers that 70% of use cases which
represent a good starting
point. The code is already Apache licensed and
junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the
month anymore, usage of
introspection and reflection is gaining more and
more importance since
more and more frameworks are depending on it and
gaining popularity
(JPA, IOC containers like Spring, alternative
serializations like JSON
and so on), and many of them are currently dealing
with the generics
problems with custom code.
WDYT?
Simone
James Carman wrote:
Does anyone have code that
Re: [all] Generics and Return Type?
I think this kind of stuff is perfect for lang, since it already deals
with reflection and it is a language-level problem. It took me
FOREVER to figure out how to do that code! :) I hope it can help
someone else.
On Wed, Sep 24, 2008 at 4:07 AM, Simone Gianni [EMAIL PROTECTED] wrote:
Hi James and Matt, and thank you for answering.
James' code is nice, and it is exactly what I was talking about. Anyway,
it covers one of the possible needs : the return type of a method; while
also parameters can be parametrized and in some situations (like a List)
simply knowing which type the programmer has assigned to a specified
generic declaration will be enough for reflection to work.
I suppose I will merge James' code, which is by far faster and cleaner
than mine, in my library. What I'd like to know is if there is space
for such a library somewhere here in Commons, and it seems like lang
could be interested. In that case, I will complete it and clean it up a
little and then contribute it to lang.
Simone
James Carman wrote:
Specifically, take a look at:
http://svn.apache.org/repos/asf/commons/proper/proxy/branches/version-2.0-work/src/main/java/org/apache/commons/proxy/invoker/recorder/InvocationRecorder.java
That's where I do my recording stuff. And, in there, I've got code
that resolves the return types of generified methods.
On Tue, Sep 23, 2008 at 4:25 PM, Matt Benson [EMAIL PROTECTED] wrote:
James later wrote some code to do this, which is in a
branch of Commons Proxy. I think we should add
something similar to the reflect subpackage (in trunk)
of the [lang] component, given the fact that BeanUtils
is in maintenance mode.
-Matt
--- Simone Gianni [EMAIL PROTECTED] wrote:
Hi all,
sorry for reopening such an old thread, but it's the
latest I've found
searching for generics.
As James say, it is quite a pain to determine types
in a generic class.
I think commons could be a good place for a library
that makes this
operation easier, maybe in beanutils since its
mission is to provide
easy-to-use wrappers around [these capabilities |
Reflection and
Introspection], and I'm writing such a library
(actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types,
like local variables,
it is still possible for subclasses explicitly
extending a generic type
with concrete types and for fields declared as non
generics to obtain
vital informations about the type of generic fields
and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the
People.add() method will
accept a Person, and the names.get() method will
return a String.
Unfortunately, it is quite complex to determine it,
cause Sun decided to
use only 4 interfaces, and force the user to make
continuous blind casts
between them.
JRE currently seems not to provide an alternative
simple solution, nor
using reflection nor introspection. Even worse,
given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends
GenericBeanPerson,
Introspection (and so BeanUtils) will return the
type of the myGeneric
property as java.lang.Object, but trying to set the
property to any
value which is not a Person will cause a
ClassCastException at runtime
because of explicit cast in bridging methods
(methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter
gets overridden in
a subclass: in that case the compiler requires that
the concrete type
is used, thus making the getters and setter appear
as having different
types, and causing problems both in Introspector and
BeanUtils.
I had this problem recently in my Apache Lab, and
wrote a (simple, not
yet complete nor optimized, but functioning) wrapper
around Class and
Method to obtain this informations. It works also in
obscure situations
where a generics is extended by a chain of classes
and determining the
actual type require recursion on superclasses while
remapping all
generic declarations from the concrete one up to
the generic one.
I don't think it is yet able to handle all possible
situations, but I
think it covers that 70% of use cases which
represent a good starting
point. The code is already Apache licensed and
junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the
month anymore, usage of
introspection and reflection is gaining more and
more importance since
more and more frameworks are depending
Re: [all] Generics and Return Type?
James Carman wrote: I think this kind of stuff is perfect for lang, since it already deals with reflection and it is a language-level problem. It took me FOREVER to figure out how to do that code! :) I hope it can help someone else. Hi James, I can perfectly understand, at the third time I had to write it, I decided to search for something already done (for example here in commons :) ), found nothing, so decided to write a good wrapper once and ease the pain of figuring out how those 4 evil interfaces behave every time. Even for that prototype I currently have in the lab it took me several hours (to understand better how it works, you can find test classes here http://svn.apache.org/repos/asf/labs/magma/trunk/foundation-basics/src/test/java/org/apache/magma/basics/utils/ ). Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
James later wrote some code to do this, which is in a
branch of Commons Proxy. I think we should add
something similar to the reflect subpackage (in trunk)
of the [lang] component, given the fact that BeanUtils
is in maintenance mode.
-Matt
--- Simone Gianni [EMAIL PROTECTED] wrote:
Hi all,
sorry for reopening such an old thread, but it's the
latest I've found
searching for generics.
As James say, it is quite a pain to determine types
in a generic class.
I think commons could be a good place for a library
that makes this
operation easier, maybe in beanutils since its
mission is to provide
easy-to-use wrappers around [these capabilities |
Reflection and
Introspection], and I'm writing such a library
(actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types,
like local variables,
it is still possible for subclasses explicitly
extending a generic type
with concrete types and for fields declared as non
generics to obtain
vital informations about the type of generic fields
and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the
People.add() method will
accept a Person, and the names.get() method will
return a String.
Unfortunately, it is quite complex to determine it,
cause Sun decided to
use only 4 interfaces, and force the user to make
continuous blind casts
between them.
JRE currently seems not to provide an alternative
simple solution, nor
using reflection nor introspection. Even worse,
given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends
GenericBeanPerson,
Introspection (and so BeanUtils) will return the
type of the myGeneric
property as java.lang.Object, but trying to set the
property to any
value which is not a Person will cause a
ClassCastException at runtime
because of explicit cast in bridging methods
(methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter
gets overridden in
a subclass: in that case the compiler requires that
the concrete type
is used, thus making the getters and setter appear
as having different
types, and causing problems both in Introspector and
BeanUtils.
I had this problem recently in my Apache Lab, and
wrote a (simple, not
yet complete nor optimized, but functioning) wrapper
around Class and
Method to obtain this informations. It works also in
obscure situations
where a generics is extended by a chain of classes
and determining the
actual type require recursion on superclasses while
remapping all
generic declarations from the concrete one up to
the generic one.
I don't think it is yet able to handle all possible
situations, but I
think it covers that 70% of use cases which
represent a good starting
point. The code is already Apache licensed and
junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the
month anymore, usage of
introspection and reflection is gaining more and
more importance since
more and more frameworks are depending on it and
gaining popularity
(JPA, IOC containers like Spring, alternative
serializations like JSON
and so on), and many of them are currently dealing
with the generics
problems with custom code.
WDYT?
Simone
James Carman wrote:
Does anyone have code that can take care of this
situation:
ListString strings = new ArrayListString();
Class returnType =
getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String.
Does anyone have code
that would return that? Is it possible?
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Simone GianniCEO Semeru s.r.l.
Apache Committer
MALE human being programming a computer
http://www.simonegianni.it/
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
Specifically, take a look at:
http://svn.apache.org/repos/asf/commons/proper/proxy/branches/version-2.0-work/src/main/java/org/apache/commons/proxy/invoker/recorder/InvocationRecorder.java
That's where I do my recording stuff. And, in there, I've got code
that resolves the return types of generified methods.
On Tue, Sep 23, 2008 at 4:25 PM, Matt Benson [EMAIL PROTECTED] wrote:
James later wrote some code to do this, which is in a
branch of Commons Proxy. I think we should add
something similar to the reflect subpackage (in trunk)
of the [lang] component, given the fact that BeanUtils
is in maintenance mode.
-Matt
--- Simone Gianni [EMAIL PROTECTED] wrote:
Hi all,
sorry for reopening such an old thread, but it's the
latest I've found
searching for generics.
As James say, it is quite a pain to determine types
in a generic class.
I think commons could be a good place for a library
that makes this
operation easier, maybe in beanutils since its
mission is to provide
easy-to-use wrappers around [these capabilities |
Reflection and
Introspection], and I'm writing such a library
(actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types,
like local variables,
it is still possible for subclasses explicitly
extending a generic type
with concrete types and for fields declared as non
generics to obtain
vital informations about the type of generic fields
and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the
People.add() method will
accept a Person, and the names.get() method will
return a String.
Unfortunately, it is quite complex to determine it,
cause Sun decided to
use only 4 interfaces, and force the user to make
continuous blind casts
between them.
JRE currently seems not to provide an alternative
simple solution, nor
using reflection nor introspection. Even worse,
given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends
GenericBeanPerson,
Introspection (and so BeanUtils) will return the
type of the myGeneric
property as java.lang.Object, but trying to set the
property to any
value which is not a Person will cause a
ClassCastException at runtime
because of explicit cast in bridging methods
(methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter
gets overridden in
a subclass: in that case the compiler requires that
the concrete type
is used, thus making the getters and setter appear
as having different
types, and causing problems both in Introspector and
BeanUtils.
I had this problem recently in my Apache Lab, and
wrote a (simple, not
yet complete nor optimized, but functioning) wrapper
around Class and
Method to obtain this informations. It works also in
obscure situations
where a generics is extended by a chain of classes
and determining the
actual type require recursion on superclasses while
remapping all
generic declarations from the concrete one up to
the generic one.
I don't think it is yet able to handle all possible
situations, but I
think it covers that 70% of use cases which
represent a good starting
point. The code is already Apache licensed and
junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the
month anymore, usage of
introspection and reflection is gaining more and
more importance since
more and more frameworks are depending on it and
gaining popularity
(JPA, IOC containers like Spring, alternative
serializations like JSON
and so on), and many of them are currently dealing
with the generics
problems with custom code.
WDYT?
Simone
James Carman wrote:
Does anyone have code that can take care of this
situation:
ListString strings = new ArrayListString();
Class returnType =
getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String.
Does anyone have code
that would return that? Is it possible?
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Simone GianniCEO Semeru s.r.l.
Apache Committer
MALE human being programming a computer
http://www.simonegianni.it/
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [all] Generics and Return Type?
Hi all,
sorry for reopening such an old thread, but it's the latest I've found
searching for generics.
As James say, it is quite a pain to determine types in a generic class.
I think commons could be a good place for a library that makes this
operation easier, maybe in beanutils since its mission is to provide
easy-to-use wrappers around [these capabilities | Reflection and
Introspection], and I'm writing such a library (actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types, like local variables,
it is still possible for subclasses explicitly extending a generic type
with concrete types and for fields declared as non generics to obtain
vital informations about the type of generic fields and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the People.add() method will
accept a Person, and the names.get() method will return a String.
Unfortunately, it is quite complex to determine it, cause Sun decided to
use only 4 interfaces, and force the user to make continuous blind casts
between them.
JRE currently seems not to provide an alternative simple solution, nor
using reflection nor introspection. Even worse, given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends GenericBeanPerson,
Introspection (and so BeanUtils) will return the type of the myGeneric
property as java.lang.Object, but trying to set the property to any
value which is not a Person will cause a ClassCastException at runtime
because of explicit cast in bridging methods (methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter gets overridden in
a subclass: in that case the compiler requires that the concrete type
is used, thus making the getters and setter appear as having different
types, and causing problems both in Introspector and BeanUtils.
I had this problem recently in my Apache Lab, and wrote a (simple, not
yet complete nor optimized, but functioning) wrapper around Class and
Method to obtain this informations. It works also in obscure situations
where a generics is extended by a chain of classes and determining the
actual type require recursion on superclasses while remapping all
generic declarations from the concrete one up to the generic one.
I don't think it is yet able to handle all possible situations, but I
think it covers that 70% of use cases which represent a good starting
point. The code is already Apache licensed and junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the month anymore, usage of
introspection and reflection is gaining more and more importance since
more and more frameworks are depending on it and gaining popularity
(JPA, IOC containers like Spring, alternative serializations like JSON
and so on), and many of them are currently dealing with the generics
problems with custom code.
WDYT?
Simone
James Carman wrote:
Does anyone have code that can take care of this situation:
ListString strings = new ArrayListString();
Class returnType = getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String. Does anyone have code
that would return that? Is it possible?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Simone GianniCEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[all] Generics and Return Type?
Does anyone have code that can take care of this situation: ListString strings = new ArrayListString(); Class returnType = getReturnType(strings.getClass(), get, int.class); I want the returnType to be java.lang.String. Does anyone have code that would return that? Is it possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
2008/4/9, James Carman [EMAIL PROTECTED]: Does anyone have code that can take care of this situation: ListString strings = new ArrayListString(); Class returnType = getReturnType(strings.getClass(), get, int.class); I want the returnType to be java.lang.String. Does anyone have code that would return that? Is it possible? It's not possible: http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html snip Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. /snip Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
Well, I figured out a way to have proxy determine the type of a method
when doing invocation recording. It took me a while, but I got it.
The code is checked into the proxy 2.0 branch. Now, I've got my
builders working for commons-expression, too! :)
On Wed, Apr 9, 2008 at 6:30 PM, Michael Heuer [EMAIL PROTECTED] wrote:
On Wed, 9 Apr 2008, Antonio Petrelli wrote:
2008/4/9, James Carman [EMAIL PROTECTED]:
Does anyone have code that can take care of this situation:
ListString strings = new ArrayListString();
Class returnType = getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String. Does anyone have code
that would return that? Is it possible?
It's not possible:
http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
snip
Generics are implemented by type erasure: generic type information is
present only at compile time, after which it is erased by the
compiler.
/snip
Right, you can get at the declared type(s) with e.g.
ListString strings = new ArrayListString();
ParameterizedType parameterizedType = (ParameterizedType)
strings.getClass().getGenericSuperclass();
Type[] types = parameterizedType.getActualTypeArguments();
System.out.println(Arrays.asList(types));
[E]
static class StringList extends ArrayListString { }
ListString strings = new StringList();
ParameterizedType parameterizedType = (ParameterizedType)
strings.getClass().getGenericSuperclass();
Type[] types = parameterizedType.getActualTypeArguments();
System.out.println(Arrays.asList(types));
[class java.lang.String]
but not the runtime type(s).
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
