harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [vmi] Reflection support for generics
Date Wed, 27 Dec 2006 12:06:33 GMT
There is HARMONY-2052 expressing exactly the same idea.
Paulex, are you going to work on this?

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

Mime
View raw message