[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] BCEL to ASM

Some more (post 1.5.0!) thoughts from me on this. One of the things I'd like to consider doing in the codebase that would crisp up the weaver abstraction and make the BCEL boundary clearer is to make the main backbone of the compiler/weaver be based on Spring beans wired together using DI. I believe this would make the architecture much clearer and make it easier for us to swap component implementations (for example, different worlds for type resolution). With that foundation, we could then do a serious proof-of-concept exercise implementing some non-trivial weaver component with ASM. Only by doing such an exercise looking at how ASM fits into the architecture, how easy it is to use for our use cases (quite intensive) and how it performs in terms of execution time and memory usage vs. the AspectJ modified BCEL can we make a sensible decision. The goal of the PoC is to implement enough that we can make an informed go/no-go decision.

Remember that users don't (or really shouldn't if they do) care how the AspectJ compiler does what it does. So swapping out BCEL for ASM is not a great user feature to expend developer resource on unless:

* we get much better weave times
* and/or we get much reduced memory usage
* and/or we can turn around bug reports quicker through a simplified implementation
* and/or future development can progress at an increased pace for the same reasons
* AND we don't destabilise the implementation which has been battle-hardened for several years now

The expectation is that ASM can deliver some or maybe even all of these benefits, but we need to see this for real in our own code base before fully commiting.

-- Adrian

Alexandre Vasseur <avasseur@xxxxxxxxx>
Sent by: aspectj-dev-bounces@xxxxxxxxxxx

15/06/2005 09:29

Please respond to
Alexandre Vasseur <avasseur@xxxxxxxxx>; Please respond to
AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>

AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
[aspectj-dev] BCEL to ASM


I would like to bring to the table the following risk that we had
foresight in AspectWerkz and for which I would not be suprised if it
really happens by Q1 2006.

"proposal to post deprecation notice on BCEL webpage"
(read some the related thread if you have time).

I would invite everyone concerned with AspectJ dev to think about
possible implication of maintaining as done today the modified
enhanced BCEL version, as well as thinking about the development
effort and risks associated to port AspectJ to ASM at some stage - not
for prototyping purpose or abstraction purpose but for the real
official N-th release.

aspectj-dev mailing list