I like it, a bold statement :) So, questions to the BCEL community.
1) Does BCEL have use-cases over ASM? I think Eugene's statement is a healthy, competitive one and it'd be good to hear if there's disagreement. 2) If Eugene is right, a) are there features in the planning to give BCEL a use-case? b) should the focus be on fixing bugs for existing users instead of adding features that ASM has already. Hen (DISCLAIMER: This is all definitely _without_ the PMC chair hat on. Mainly just the librarian in me wanting to classify BCEL and ASM etc) On 5/8/05, Eugene Kuleshov <[EMAIL PROTECTED]> wrote: > Henri, > > I do believe that at present moment there is absolutely no point to > use BCEL for any new project. ASM can completely cover anything you > would need for bytecode manipulation and will give better performance. > > regards, > Eugene > > Henri Yandell wrote: > > On 5/3/05, Eugene Kuleshov <[EMAIL PROTECTED]> wrote: > > > >>Henri, > >> > >> I'm not sure what else you need from ASM's DOM. It is sufficient > >>enough for the purpose. It may not provide a complete type/opcode > >>safety, but it is more lightweight from a memory point of view. > > > > > > The SAX/DOM metaphor had been at the heart of a thread discussing > > whether BCEL had technical reasons to be used rather than ASM. After > > Eric's email in which he points out that both libraries can do DOM and > > SAX style APIs, but that the difference is which one is on top, I'm > > wondering what reasons the ASM guys would give to use BCEL instead of > > ASM, or whether ASM felt they would be a complete replacement for > > BCEL's feature-set sometime in the future. > > > > Ideally I'd result in a "When to use ASM, when to use BCEL and when to > > use SERP" style of document. Would be nice for the BCEL site I think. > > > > Hen > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
