There is HARMONY-2052 expressing exactly the same idea. Paulex, are you going to work on this?
-- 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
