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.
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. 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: 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); ... 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. -- Alexey 2007/1/11, Yang Paulex <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > > There is HARMONY-2052 expressing exactly the same idea. > Paulex, are you going to work on this? > > -- > 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 Labotary IBM
