harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject [vmi] Reflection support for generics
Date Tue, 26 Dec 2006 10:02:32 GMT
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?

-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message