harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [OT] Earthquake in Taiwan (Re: [vmi] Reflection support for generics)
Date Thu, 28 Dec 2006 15:38:14 GMT
On 12/28/06, Geir Magnusson Jr. <geir@pobox.com> 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. <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
> >
> >
>
>


-- 
Best regards,
Andrew Zhang

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message