aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject RE: Another weaving problem?
Date Sat, 04 Jun 2011 08:40:33 GMT

> Subject: Re: Another weaving problem?
> From:
> Date: Fri, 3 Jun 2011 19:55:35 +0100
> To:
> Alasdair Nottingham
> On 3 Jun 2011, at 19:32, Kevan Miller  wrote:
> >
> > On Jun 3, 2011, at 12:55 PM, Alasdair Nottingham wrote:
> >
> >> On 3 June 2011 16:29, Kevan Miller  wrote:
> >>>
> >>> On Jun 3, 2011, at 11:10 AM, David Jencks wrote:
> >>>
> >>>> I'm tired of being in the middle of this. Please discuss this on the
owb dev list or in comments to
> >>>
> >>> :)
> >>>
> >>>>
> >>>> The problem in owb is that although the actual proxy building code has
no problems with the final synthetic methods, there's an excessively naive check for proxyability
that just looks at all declared methods and checks they aren't final. Based on this example,
I think there may be a lot of existing code with similar errors that works fine in most situations
but will not work with aries.
> >>>
> >>> I'm worried about this, also.
> >>>
> >>> IIUC, complexity has been added to detect the classes so that we can make
these methods 'final' -- not for semantic understanding, but in the hopes of improved JIT
behavior. As you note, there is the potential that this will cause incompatibilities/problems
with other libraries.
> >>
> >> I think Richard gave other reasons as to why these methods should be
> >> marked final. So it isn't just around performance.
> >
> > Richard gave a reason for why someone might want to make a method final. I don't
think he was saying anything specific (one way or another) about *these* specific methods.
> >
> I think he meant to. Although at this point we need him to come back and clarify.

I also made this point a while back, though it hasn't been referenced since. Re-including
the relevant parts of the email I sent earlier.



I would like to quickly point out that the method java.lang.reflect.Method#isSynthetic() gives
you access to the synthetic flag in a very easy way. 
My understanding from JIT implementors has always been that final is a good thing for performance.
I also like the additional safety it adds to the proxy code, preventing us accidentally overriding
our own implementations.
I do think overriding synthetic methods when proxying is a reasonably bad idea, similarly
for bridge methods, which I imagine are also overridden. Intercepting these calls gives the
wrong behaviour unless you are extremely careful. Obviously I'm not part of the OWB discussion,
and they may be making valid points. For clarity we avoid weaving/overriding synthetic, static,
private, bridge, abstract or native modified methods in Aries code.


The proxy weaving code is as minimally invasive as we could make it, one of the ways we did
that was to implement as much of the WovenProxy code as we could at the top of the class hierarchy,
inheriting it all the way down. This also makes sure we don't end up with broken proxys that
use one dispatcher/listener for some methods and another for other methods. When working together
Richard and I chose to make these implementations final for three main reasons.

1. To ensure we weren't adding the methods multiple times
2. To make it less likely someone would accidentally start adding the methods multiple times
when maintaining the proxy code
3. Because it improves performance

I'm pretty certain that Richard was trying to highlight points 1 and 2, which were lost among
the other points in my original mail.



> > --kevan
View raw message