Re: [aspectj-dev] BCEL vs ASM

[Alexandre Vasseur <avasseur@xxxxxxxxx>]

That s indeed what we have in our head.

I personnaly love ASM. In AW we have tried them all (almost). The
first version was using Bcel , and we had to ship our own version as
well.. The 1.x came with Javassist, and this one is easy to use but
prooves to be frustrative when you want to do advanced things.
The 2.x is fully ASM based.

ASM is really easy to work with when you have this "visitor" concept
in the head (that Bcel mimics as well if you want), but indeed, it is
rather intrusive since it does not yet provides a reflective like API
ie an API where you manipulate sort of class on which you add /
iterate methods etc ala Bcel / Javassist.

The footprint of ASM is very low, but in an AOP concern, it is
required to f.e. sometime know from the bytecode, the super class and
super super class of the current weaved class (to resolve pointcuts
matching). ASM won't help you there, while Bcel does most of the job
for you (or is expected to do it..). This means that the fooprint will
still gets bigger due to the fact that you will need this information.
You won"t say that it is an ASM issue, it will be your own issue this
time.. And for sure, from a user point of view it is the same, hence
our concern about that issue and the Adrian exposed plan.

Note that my comments are about the weaver. The aspect compiler is
using Eclipse CodeStream API which is also a sort of a visitor based
thing. I don't think this one is worth changing to ASM even in the
long run (though probably possible as well). What do you think ?

Alex






On Tue, 25 Jan 2005 10:24:14 +0000, Adrian Colyer
<adrian_colyer@xxxxxxxxxx> wrote:
> It's not a stupid question... we've spent a good few hours deliberating
> this.
> 
> AspectJ's weaver has an interface layer into which BCEL implementations
> are plugged, so in theory we're well positioned to use ASM (I haven't
> looked at the licensing issues). However, BCEL is the only implementation
> that's ever been plugged into that interface so there have almost
> certainly been some BCEL 'leaks' and the interface won't be perfect. The
> big con of switching is that we have an existing BCEL implementation which
> works and is validated by a large user community. (Our BCEL is also
> significantly different to an "off-the-shelf" BCEL - it's much faster, has
> some critical bug fixes, and supports Java 5 for starters). We decided
> that doing two major changes in one go (Java 5 support and a BCEL swap)
> was not sensible and so opted to continue building on BCEL for 1.5.0. Once
> we get 1.5.0 stabilized though, weaver performance and memory usage are
> important areas we want to focus on. Especially with Jonas and Alex
> joining the project (and bringing their ASM experience with them) we'll be
> collectively taking a long hard look at this question and deciding on what
> to do. We'll do some initial proof-of-concept to validate the benefits of
> the switch, if they outweigh the risk of doing the work, then AspectJ
> could well be on ASM before the year is out.
> 
> -- Adrian
> Adrian_Colyer@xxxxxxxxxx
> 
> Kev Jackson <kevin.jackson@xxxxxxxxxxxxx>
> Sent by: aspectj-dev-admin@xxxxxxxxxxx
> 25/01/2005 09:46
> Please respond to
> aspectj-dev@xxxxxxxxxxx
> 
> To
> aspectj-dev@xxxxxxxxxxx
> cc
> 
> Subject
> [aspectj-dev] BCEL vs ASM
> 
> 
> I'm new here, so I'm probably asking a stupid question, but...
> 
> Would it be possible to replace BCEL with ASM[1]?  Does it provide the
> same level of manipulation that BCEL does, and if so what's the reason
> for not using it?
> 
> Pros for switching to ASM:
> - smaller jar, so smaller distribution of AspectJ
> - allegedly much faster
> - allegedly more memory efficient
> 
> Cons
> - license issue?
> - compatibility issues
> 
> Any thoughts?
> 
> Kev
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>