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. <[EMAIL PROTECTED]>:
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
