harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject [OT] Earthquake in Taiwan (Re: [vmi] Reflection support for generics)
Date Thu, 28 Dec 2006 14:00:17 GMT

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?

I heard it will take weeks to fix the fibre...

geir

>>
>> -- 
>> 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