Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <f2e8eedf0809231656p3fc44a49nff22229648b97654@mail.gmail.com>
Date: Tue, 23 Sep 2008 19:56:30 -0400
From: "James Carman" <james@carmanconsulting.com>
Sender: jcarman@carmanconsulting.com
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [all] Generics and Return Type?
In-Reply-To: <54648.56768.qm@web55108.mail.re4.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48D77E86.6030305@apache.org>
	 <54648.56768.qm@web55108.mail.re4.yahoo.com>

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 <gudnabrsam@yahoo.com> 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 <simoneg@apache.org> 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 List<String> names;
>>   public class People implement List<Person> { }
>>
>> 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 GenericBean<T> {
>>   private T myGeneric;
>>   public T getMyGeneric() { return myGeneric; }
>>   public void setMyGeneric(T v) { myGeneric = v; }
>> }
>>
>> Even subclassing it like "PersonBean extends
>> GenericBean<Person>",
>> 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:
>> >
>> > List<String> strings = new ArrayList<String>();
>> >
>> > 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:
>> dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >
>> >
>>
>>
>> --
>> Simone Gianni            CEO Semeru s.r.l.
>> Apache Committer
>> MALE human being programming a computer
>> http://www.simonegianni.it/
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org