[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Torsten Curdt wrote:
While I do think that BCEL has miserably failed from the
community perspective it is still being used in so many projects
that we should not just let the users down. The costs of switching
from BCEL to ASM might be just too high.
That actually could be a good summer project... E.g. build some
intermediate bridge that would use ASM underneath or some kind of source
code analyzer/transformer to help with straight migration from BCEL to
ASM tree API (maybe even as simple as Jackpot rules, or somehow reuse
Eclipse's binary refactorings). I've been looking on such conversion
process at some point and it seems there is big similarity between BCEL
and ASM.
From the API perspective the BCEL approach is surely a bit more
straight forward than ASM ...and easier to handle in some areas.
Also performance was never an issue for me yet.
We've been asking users how to make tree API easier to use in ASM. So,
what exactly are those areas that easier to handle with BCEL?
BTW, Eric just posted proposal for changes in tree API for ASM 3,
which should address several old issues, including random insertion into
the list of method instructions and improved performance of scanning
trough instructions to another 8%.
But starting a new project as a user I would probably go with ASM
as this community just rocks. They have a kick-ass eclipse plugin
and they support their user base very well.
I guess we do. :-) But we could use some feedback...
regards,
Eugene
