[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[aspectj-dev] Re: reflective calls
- From: Alexandre Vasseur <avasseur@xxxxxxxxx>
- Date: Fri, 17 Jun 2005 12:47:37 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GZB4MMY+CjZrtwAb9B+64rbrnzH4gLFOXQ9p5YlG+p7f286eR3Mj1XxGqiH8wm2zVGZM3fS7GfgWs/RFhH5wdbntb2dBP3v18DbubhJ1scn8d2LS5MdBQKRuWudJo20l3ZOhxTU82gMO1HDJP+5hW6YCRm4OOEjFSW1uCtpAT8w=
The question may then be: if someone implements an AspectJ weaver (as
the trend starts to surface thru ABC and JRockit) would there be a
need for an option to turn on/off this reflective call matching.
Note that as I said some aspect can be added to handle that as well in
weavers that don't have the capability to do this kind of matching.
The same question would be raised if f.e. one would ask for an AspectJ
TCK, or more generally with "what is the call pointcut exact behavior"
(no matter the language beehind - reflection is existing in .Net if I
On 6/17/05, Jonas Bonér <jboner@xxxxxxxxx> wrote:
> Hi Eric.
> I agree that this is not problem related to AspectJ, but related to
> how weaving is done (weaving meaning both the analysis and the actual
> As an example, when we implemented the AOP support in the JRockit JVM
> (with AspectJ as the front-end) this problem solved itself, since the
> VM sees no difference between reflective call in a regular call.
> On 6/17/05, Eric Bodden <eric@xxxxxxxxx> wrote:
> > Alexandre Vasseur wrote:
> > > I have been asked what is the "AspectJ answer" to "how to match
> > > reflective calls" such as with:
> > Hi, Alex. The issue you are raising is actually not an AspectJ specific
> > problem. It's indeed a problem for any program which employs
> > interprodedural
> > analysis as well. Up till now I have seen no decent solution to this
> > problem, which does not surprise me because I think there actually cannot
> > be
> > one. The one possible method you mentioned (runtime matching) is actually
> > the only possible way IMHO since obviously *any possible String* could be
> > passed in to Method.invoke(...). What this String looks like cannot
> > generally be determined statically. Thus runtime evaluation/matching is
> > unavoidable for a general solution.
> > Hope that helps,
> > Eric
> > --
> > Eric Bodden
> > Chair I2 for Programming Languages and Program Analysis
> > RWTH Aachen University
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev