On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 27, 2006, at 10:51 PM, Paulex Yang wrote: > 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.... I heard about this - it was reported as offshore and main effect was cutting of fibre optic cables? Was anyone hurt?
It's reported that 2 people were killed, and 47 people were injured. I heard it will take weeks to fix the fibre... I can't access Harmony website, svn ... It's a good execuse for taking a rest. :) geir
>> >> -- >> 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 > >
-- Best regards, Andrew Zhang
