harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [vmi] Reflection support for generics
Date Thu, 28 Dec 2006 03:51:05 GMT
Alexey Varlamov wrote:
> There is HARMONY-2052 expressing exactly the same idea.
> Paulex, are you going to work on this?
Sure, I'm very happy to...but unfortunately I got some serious network 
problem to access ASF infrastructure(Jira/SVN, etc...) recently(it is 
said that due to the earthquake in Taiwan yesterday, wish the people 
involved good luck...)...so I may need a little more time to look at it....
>
> -- 
> Alexey
>
> 2006/12/27, Geir Magnusson Jr. <geir@pobox.com>:
>>
>> On Dec 27, 2006, at 6:00 AM, Tim Ellison wrote:
>>
>> > Paulex Yang wrote:
>> >> Hi, all
>> >>
>> >> I found that IBM VME's kernel class implementation don't fully
>> >> support
>> >> generics related reflection, more specifically, the methods below
>> >> always
>> >> return null: (Oli? would you like to confirm?)
>> >>
>> >> j.l.r.Constructor.getGenericParameterTypes()
>> >> j.l.r.Constructor.getGenericExceptionTypes()
>> >> j.l.r.Field.getGenericType()
>> >> j.l.r.Method.getGenericReturnType()
>> >> j.l.r.Method.getGenericParameterTypes()
>> >> j.l.r.Method.getGenericExceptionTypes()
>> >> java.lang.Class.GetGenericInterfaces()
>> >> java.lang.Class.GetGenericSuperclass()
>> >>
>> >> So I looked at DRLVM's j.l.r.Constructor implementation, seems most
>> >> codes related generics reflection are VM neutral, such as classes in
>> >> o.a.h.l.r.parser, except several small native methods locate in
>> >> o.a.h.v.VMGenericsAndAnnotations to access class flags, I haven't
>> >> looked
>> >> into other classes but I won't be surprised if they aren't in similar
>> >> case. If so, it makes sense to me to extract the VM independent part
>> >> into class library codes as utilities, so that IBM VME(and other
>> >> Harmony
>> >> compatible VM) can also benefit from them, one obvious drawback
>> >> may be
>> >> some new VMI methods needed to access the VM implementation details.
>> >> Because lack of enough knowledge on either IBM VME or DRLVM
>> >> implementation, I'm not sure if it is a good idea. So any comments
>> >> from
>> >> DRL gurus and others?
>> >
>> > I know that you were asking for DRL gurus, but...
>> >
>> > this makes sense to me, looking at the logic in the DRLVM-specific
>> > types
>> > it appears that we can share that non-trivial logic across VM's and
>> > reduce the VM-specific parts to retrieving the raw data and calling
>> > those helpers.
>> >
>> > The logic place for such shared types would be in
>> > o.a.h.luni.internal.reflect.  Of course, it does not preclude VMs
>> > dealing with the API entirely themselves and not delegating to the
>> > helpers if they so choose.
>>
>> +1
>>
>> >
>> > Regards,
>> > Tim
>>
>>
>


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message