Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexey.v.varlamov@gmail.com
 designates 64.233.184.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mLYE1Vp1Eavd17mnFnm19vnWWn3dFu4cd7jD8DUGqYIyoVicMTvxD+cVOCSTQyX14v2PD7EkQ8hgBG5yGZKG5Fg5sdgympBr1PkPyTjYd3eMTlJLi7L08Ic8D6XQ845Ue8jC3XdYm7dCni0QHUSWCES8hUBUytpQi75oIsqq8Ec=
Message-ID: <f944d83d0701112040k22bff760hbe0be8df4a4d6b99@mail.gmail.com>
Date: Fri, 12 Jan 2007 10:40:08 +0600
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [vmi] Reflection support for generics
In-Reply-To: <f982cec50701111949w4ff576f6ncfbdec16660a780c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4590F338.2050601@gmail.com> <4592525E.9020509@gmail.com>
	 <16ACCAB9-8CA8-4354-B3F9-4A4AAF096671@pobox.com>
	 <f944d83d0612270406j6633fa38g6246c31ff277af1@mail.gmail.com>
	 <f982cec50701110058g6f0e6d53q29ef4a490fb5a256@mail.gmail.com>
	 <f944d83d0701110532r1d19a005ofbf822ef72a185eb@mail.gmail.com>
	 <f982cec50701111949w4ff576f6ncfbdec16660a780c@mail.gmail.com>

2007/1/12, Yang Paulex <paulex.yang@gmail.com>:
> 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.
OK, thank you. Good luck ;)

[snip]
>
> 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:(.
That's right, the signature is specific to class file format and is
not exposed anywhere. My speculation was it could be possible to go
with recursive callbacks to public API instead of VMI extension, but
it seems tricky to verify without going deeper into implementation
details. So I'm OK with the 2) as it enables more impl freedom.

> About the getSignature(AccessibleObject), it's needed by ConstructorData,
> etc, but not by the reflection parser classes.
I see, and my suggestion to sort out the parser first is still valid :)

>
> 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.
The inner classes also handle annotations and other reflection data so
have other dependencies as well, though indeed not related to
generics.
But don't be confused by finding generics-related code in those
classes, such code should belong to the parser actually - this is just
an example of spaghetti-ness which I talked above.
[snip]

--
Alexey