Re: comparison between BCEL and ASM

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
> 
>