harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: [vmi] Reflection support for generics
Date Fri, 12 Jan 2007 03:49:11 GMT
inline.

2007/1/11, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
>
> Hello Paulex,
>
> Actually I thought about reversed order of steps, i.e. clean up impl
> first then move it.
> The point is that current impl is spaghetti-like, entangled with
> internals of kernel classes. The very 1st step I suggest to get rid of
> all o.a.h.l.reflect.** import clauses in j.l.Class except the Parser
> itself (currently there are 16(!) imported classes). After that we'll
> have more neat API and will better understand really needed
> dependencies. Please ask if you need any assistance, I'm happy to take
> part.


Sounds reasonable, so I'll look into the implementation now, and I'll raise
my thoughts here after then.

I do not quite understood 1), because the AuxiliaryChecker does not
> belong to public API so cannot stay as kernel class. Regarding its'
> purpose, I guess it implements some reflectionAPI-mandated checks,
> e.g. this is the only code throwing
> MalformedParameterizedTypeException, which is declared to be thrown by
> public javadocs.


I see, thank you:)

The 2) looks reasonable, except I do not think one ever needs
> getSignature(AccessibleObject). Signatures of members are only needed
> as input parameters to the parser.
> And probably even getSignature(Class) is not needed, parser could do
> just with public reflection API - though I did not try to verify this
> speculation. So if the latter is true, we also have other option:


I did think the signature can be got by public API, but I didn't find it:(.
About the getSignature(AccessibleObject), it's needed by ConstructorData,
etc, but not by the reflection parser classes.

3) Don't change VMI, export an API from classlib like this:
> Type o.a.h.l.reflect.GenericsParser.getType(String sig, Class owner);
> TypeVariable[] o.a.h.l.reflect.GenericsParser.getTypeParameters(String
> sig, Class owner);
> ...


I agree this is the objective:).

As for sharing other classes like Class.GACache,
> Constructor.ConstructorData, it may also be reasonable but would
> certainly require further VMI extension. Let's do it step by step and
> manage the parser first.


So far I only found one more external dependency related to generics, i.e.,
the VMGenericsAndAnnotations.getSignature(long), but as inner classes, maybe
they had some coupling with their wrapper classes.

--
> Alexey
>
> 2007/1/11, Yang Paulex <paulex.yang@gmail.com>:
> > Hi, sorry for the delay, I've just got some time to look at this issue
> now.
> >
> > I tried to move generic reflection support out from kernel class to LUNI
> at
> > first, then look at the implementation itself, like JIRA-2052 requested.
> >
> > Currently I see four packages can be moved out:
> > o.a.h.l.reflect.implementation
> > o.a.h.l.reflect.parser
> > o.a.h.l.reflect.repository
> > o.a.h.l.reflect.support
> >
> > But there is one utility class o.a.l.r.s.AuxiliaryChecker, which depends
> on
> > DRLVM specific
> org.apache.harmony.vm.VMGenericsAndAnnotations.getSignature(Class),
> > so we have two options:
> >
> > 1. Don't add VMI methods, and keep AuxiliaryChecker in kernel class,
> this
> > option is relative simple. According to class comments, AuxiliaryChecker
> is
> > to check the correspondence of the formal parameter number and the
> actual
> > argument number, I'm not sure yet about its purpose to check this during
> > generics reflection.
> >
> > 2. Add VMGenericsAndAnnotations.getSignature(Class) and
> > getSignature(AccessibleObject) to VMI kernel class contract, please note
> > that the latter method needs to be refactored from getSignature(long).
> This
> > option can enable more code sharing between different VMs, because
> several
> > wrapped class, say Class.GACache, Constructor.ConstructorData, etc, and
> > several other methods can be VM independent.
> >
> > I've tried run tests sucessfully for both options.
> >
> > From modularity perspective, I think the latter one seems more elegant,
> but
> > it needs new API of VMI (although trivial refactory to DRLVM), so I'd
> like
> > to hear about others' comments. And also please let me know if I missed
> > something in DRLVM. Thank you all.
> >
> > 2006/12/27, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> > >
> > > 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
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Labotary
> > IBM
> >
> >
>



-- 
Paulex Yang
China Software Development Labotary
IBM

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