You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-dev@jakarta.apache.org by BRUNETON Eric RD-MAPS-GRE <er...@francetelecom.com> on 2005/03/22 12:01:55 UTC
comparison between BCEL and ASM
Paul McLachlan wrote (14 Dec 2004) [1]:
>> Or a response from a BCEL developer to indicate what BCEL offers that
>> ASM lacks would be useful...
>
>FWIW, I looked at ASM a few months ago to see if I wanted to migrate to
>it and decided it didn't have the features I needed. I think, at the
>time, I compared the two to the difference between SAX and DOM.
>Sometimes you can do what you want with SAX, and it's faster. But
>sometimes, you really need DOM and are willing to pay for it.
>I'm in (and will always be in, with our problemspace) the latter
>camp, as far as bytecode transformation goes.
The comparison with SAX and DOM is not true: both ASM and BCEL provide a
SAX and a DOM like API. For ASM the SAX like API is in asm package, and
the DOM like API in asm.tree package. For BCEL the SAX like API is the
classfile.Visitor and generic.Visitor interfaces and the DOM like API is
the classes of the classfile and generic packages. The *real* difference
is that in ASM the DOM like API is provided on top of the SAX like API,
while in BCEL the converse is true. It is therefore possible, with ASM,
to use the SAX like API without paying the cost of DOM, which is not
possible with BCEL. Note also that the cost of the DOM like API of ASM
is much lower than in BCEL:
time to load some 1240 classes with JDK1.5: T = ~0.94 s
time to load these classes with a simple on the fly transformation:
- with ASM 2.0 SAX like API: ~1.5 s (= +60% compared to T)
- with ASM 2.0 DOM like API: ~1.84 s (= +95% compared to T)
- with BCEL 5.1 DOM like API: ~6.9 s (= +630% compared to T)
Some other differences and similarities between ASM 2.0 and BCEL 5.1 I
can think of are:
- ASM completely hides the constant pool in order to provide a simpler
API. The drawback is that it is not possible to implement
transformations that need to explicitely manipulate the constant pool
(for example to sort the constants in order to get better jar
compression ratios; in fact it is possible, but more code is required)
- ASM does not provide any equivalent for Repository (but there are
suggestions to remove this from BCEL [3]), nor any classloader related
utilities
- Both ASM and BCEL provide functions to compute maxstacksize and
maxlocals, transparently handle the "wide" opcode, and transparently
change goto and jsr to goto_w and jsr_w when needed. ASM also
transparently change if instructions to if+goto_w instructions when
needed, which is not done in BCEL (I think).
- Both ASM and BCEL allow "lazy" parsing of class files. In BCEL this is
done with the JavaClass/ClassGen distinction, in ASM by the fact that
returning null in visitField or visitMethod skips the parsing of a field
or method.
- ASM provides support for JDK1.5 class attributes, including an API to
analyze/transform/generate generic signatures. BCEL 5.1 does not provide
this, but future versions will [2, 3].
- ASMifier is similar to BCELifier. Both ASM and BCEL provide utilities
to manage type descriptors. ASM does not provide a Class2HTML, but
provides a package to convert classes to and from XML. ASM does not
provide pattern matching functions to find instruction sequences that
match a given pattern.
- ASM verifier is less complete that in BCEL (only pass3b is
implemented), but there is a framework for code analysis similar to
bcel.verifier.structurals package.
- Finally ASM is packaged in a more modular way than BCEL, and is more
compact (due to the fact that (1) some features are not implemented in
ASM - repository, full verifier, etc [but conversely some ASM features
are not provided in BCEL: JDK1.5 support], (2) the BCEL DOM like API is
much more detailled than in ASM, and (3) ASM jars are optimized - no
debug info, private member names changed to shorter names, optimized
constant pool):
ASM 2.0 BCEL 5.1 (jar sizes in KB)
SAX like API only 33 N/A
+DOM like API 49 321
+verifier 67 449
+utils 97 485
+html/xml util 145 504
Eric (ASM project leader)
[1]
http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
/%3c8103E8A9D484EB4280806F701E3FE6D1038C98D2@svexmb02.merc-int.com%3e
[2]
http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
/%3c31cc373604121319355782fad5@mail.gmail.com%3e
[3]
http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
/%3c31cc3736050131091856624204@mail.gmail.com%3e
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-05-08 at 13:05 -0400, Henri Yandell wrote:
> 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.
I'm a committer on BCEL, though mostly in order to provide
oversight/guidance as a PMC member to people who really want to work on
BCEL.
>>From my knowledge of BCEL+ASM, Eugene is absolutely right. No-one should
use BCEL for a new project.
See also:
http://marc.theaimsgroup.com/?l=bcel-dev&m=110299532713572&w=2
and this from me:
http://marc.theaimsgroup.com/?l=bcel-dev&m=110301690425183&w=2
>
> 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.
There are quite a few projects that currently use BCEL. I think those
users should be providing patches to address issues that they encounter,
and that Jakarta needs to ensure (for its own reputation) that there are
enough people around to evaluate and apply these patches. This is
currently an issue; there is really only one person around qualified to
evaluate BCEL patches (Dave Brosius) and he hasn't been particularly
active of late (no criticism intended). I would *like* to improve my
understanding of BCEL to the point where I can also evaluate patches
(mostly for the sake of Jakarta's reputation rather than any huge
personal interest in BCEL). However various commons projects have higher
priority for my time at the moment.
Of course if an existing Jakarta committer wants to get stuck in and
improve BCEL, that's fine by me. However I don't see any signs of that.
ASM is just a better-architected product, and I don't see any great
benefits in putting large amounts of work into BCEL.
Note that I'm not criticising the original BCEL developers. BCEL is much
older than ASM as far as I am aware, and newer projects are *supposed*
to be better architected than older ones.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Torsten Curdt <tc...@apache.org>.
> I like it, a bold statement :)
>
> So, questions to the BCEL community.
...the point is - there is only a *very* small
developer community but a large user community
I think the guys left over on bcel-dev are more
here for maintenance than development.
> 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.
I haven't explored all areas with ASM yet.
...but for the ones I touched it felt quick
and easy to use.
Especially with the great eclipse view.
One thing I really dislike though was the
heavy use of strings on the API.
> 2) If Eugene is right,
>
> a) are there features in the planning to give BCEL a use-case?
I've changed the javaflow API so it's now
easy to hook in an ASM implementation of
the bytecode rewriting. This will be my
use-case for comparison.
I can probably say more after that's done.
> b) should the focus be on fixing bugs for existing users instead of
> adding features that ASM has already.
Yepp ...I think that's the way to go for now.
cheers
--
Torsten
Re: comparison between BCEL and ASM
Posted by Henri Yandell <fl...@gmail.com>.
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 <eu...@md.pp.ru> 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 <eu...@md.pp.ru> 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: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Eugene Kuleshov <eu...@md.pp.ru>.
Henry,
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 <eu...@md.pp.ru> 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: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Henri Yandell <fl...@gmail.com>.
On 5/3/05, Eugene Kuleshov <eu...@md.pp.ru> 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: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: [asm] Re: comparison between BCEL and ASM
Posted by Torsten Curdt <tc...@apache.org>.
> Aside, from what we experienced in AspectWerkz, the BCEL so called
> Repository is just broken when you have some classloader hierarchies
> and multi threaded instrumentation. We ended up in writting our own
> hack for that. With ASM, we implemented our own repository, that does
> not suffer from that weakness:
> http://svn.apache.org/viewcvs.cgi/jakarta/bcel/trunk/src/java/org/apache/bcel/Repository.java?rev=152903&view=markup
> This class contains only static methods, so you have to carrully avoid
> using it (and any variant like ClassLoaderRepository) since f.e. when
> doing on the fly instrumentation, it is obvious that 2 threads can do
> instrumentation for 2 different classloader.
Yepp ...that repository stuff is just a PITA
I clearly requires some (re)design
cheers
--
Torsten
Re: [asm] Re: comparison between BCEL and ASM
Posted by Vishal Vishnoi <vv...@bea.com>.
I agree with Alex on how fast and efficient ASM is
I used it's SAX style feature in a recent project where I replaced an
existing custom
byte instrumentation engine with one that was ASM based. The abstraction
that
ASM provides (ASM completely hides the constant pool in order to provide
a simpler API....)
make it relatively easy to work with byte code.
Asmifier was really very useful in understanding the code that I needed
for modifying
byte code. Also, their tutorial on the web site is a very good starting
point.
--Vishal
P.S: Very happy and satisfied user :-)
Alexandre Vasseur wrote:
>ASM just rocks. We have implemented AspectWerkz with BCEL, with
>Javassist, and with ASM in the last 2 years, going from AspectWerkz
>0.x to 2.x
>
>ASM programming model is by far easier than the BCEL one. The memory
>footprint is much smaller as well, especially because there is no
>"Repository" in ASM and thus it is really pay as you go.
>
>Aside, from what we experienced in AspectWerkz, the BCEL so called
>Repository is just broken when you have some classloader hierarchies
>and multi threaded instrumentation. We ended up in writting our own
>hack for that. With ASM, we implemented our own repository, that does
>not suffer from that weakness:
>http://svn.apache.org/viewcvs.cgi/jakarta/bcel/trunk/src/java/org/apache/bcel/Repository.java?rev=152903&view=markup
>This class contains only static methods, so you have to carrully avoid
>using it (and any variant like ClassLoaderRepository) since f.e. when
>doing on the fly instrumentation, it is obvious that 2 threads can do
>instrumentation for 2 different classloader.
>
>ASM support for Java 5 annotation is really great, especially in 2.x,
>and it has been in since the early beta of Java 5, which is really
>important. This is fairly easy to have in BCEL, and f.e. is done in
>AspectJ (that is unfortunately still using BCEL, and even worse we
>have a modified version to have a much more lazy behavior) but that s
>obviously something you want to avoid to deal with.
>
>We implemented the whole AspectWerkz with only the "SAX" style of ASM.
> This proves it is possible to do fairly advanced transformation (yes
>sometime we do some lookahead visit, but only when we need those. In
>bcel, I would end up in iterating this memory expensive instruction
>list, going back and forth, and the resulting code will actually be
>much harder to understand and maintain).
>
>Alex
>PS: not sure if it will reach BCEL lists since I am not subscribed
>there anymore.
>
>
>
>
>On 5/3/05, Eugene Kuleshov <eu...@md.pp.ru> 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.
>>
>> ASM's verifier is actually provide a bytecode-level verification and
>>does not do type and signature checking, primarily because you'll have
>>to have some kind of class repository for this. Anyway, it is quite easy
>>to implement but I doubt that it will be really useful, because you can
>>always actually load class using VM classloader in order to perform such
>>validation.
>>
>> regards,
>> Eugene
>>
>>Henri Yandell wrote:
>>
>>
>>>Nice email, thanks.
>>>
>>>For the areas where BCEL has features that ASM does not (fuller DOM,
>>>full verifier) does ASM have plans in the works to support these at
>>>some point, or are they outside of the ASM philosophy?
>>>
>>>Hen
>>>
>>>On 3/22/05, BRUNETON Eric RD-MAPS-GRE <er...@francetelecom.com> wrote:
>>>
>>>
>>>
>>>>Paul McLachlan wrote (14 Dec 2004) [1]:
>>>>
>>>>
>>>>
>>>>>>Or a response from a BCEL developer to indicate what BCEL offers that
>>>>>>ASM lacks would be useful...
>>>>>>
>>>>>>
>>>>>FWIW, I looked at ASM a few months ago to see if I wanted to migrate to
>>>>>
>>>>>
>>>>>it and decided it didn't have the features I needed. I think, at the
>>>>>time, I compared the two to the difference between SAX and DOM.
>>>>>Sometimes you can do what you want with SAX, and it's faster. But
>>>>>sometimes, you really need DOM and are willing to pay for it.
>>>>>I'm in (and will always be in, with our problemspace) the latter
>>>>>camp, as far as bytecode transformation goes.
>>>>>
>>>>>
>>>>The comparison with SAX and DOM is not true: both ASM and BCEL provide a
>>>>SAX and a DOM like API. For ASM the SAX like API is in asm package, and
>>>>the DOM like API in asm.tree package. For BCEL the SAX like API is the
>>>>classfile.Visitor and generic.Visitor interfaces and the DOM like API is
>>>>the classes of the classfile and generic packages. The *real* difference
>>>>is that in ASM the DOM like API is provided on top of the SAX like API,
>>>>while in BCEL the converse is true. It is therefore possible, with ASM,
>>>>to use the SAX like API without paying the cost of DOM, which is not
>>>>possible with BCEL. Note also that the cost of the DOM like API of ASM
>>>>is much lower than in BCEL:
>>>>
>>>>time to load some 1240 classes with JDK1.5: T = ~0.94 s
>>>>time to load these classes with a simple on the fly transformation:
>>>>- with ASM 2.0 SAX like API: ~1.5 s (= +60% compared to T)
>>>>- with ASM 2.0 DOM like API: ~1.84 s (= +95% compared to T)
>>>>- with BCEL 5.1 DOM like API: ~6.9 s (= +630% compared to T)
>>>>
>>>>Some other differences and similarities between ASM 2.0 and BCEL 5.1 I
>>>>can think of are:
>>>>
>>>>- ASM completely hides the constant pool in order to provide a simpler
>>>>API. The drawback is that it is not possible to implement
>>>>transformations that need to explicitely manipulate the constant pool
>>>>(for example to sort the constants in order to get better jar
>>>>compression ratios; in fact it is possible, but more code is required)
>>>>
>>>>- ASM does not provide any equivalent for Repository (but there are
>>>>suggestions to remove this from BCEL [3]), nor any classloader related
>>>>utilities
>>>>
>>>>- Both ASM and BCEL provide functions to compute maxstacksize and
>>>>maxlocals, transparently handle the "wide" opcode, and transparently
>>>>change goto and jsr to goto_w and jsr_w when needed. ASM also
>>>>transparently change if instructions to if+goto_w instructions when
>>>>needed, which is not done in BCEL (I think).
>>>>
>>>>- Both ASM and BCEL allow "lazy" parsing of class files. In BCEL this is
>>>>done with the JavaClass/ClassGen distinction, in ASM by the fact that
>>>>returning null in visitField or visitMethod skips the parsing of a field
>>>>or method.
>>>>
>>>>- ASM provides support for JDK1.5 class attributes, including an API to
>>>>analyze/transform/generate generic signatures. BCEL 5.1 does not provide
>>>>this, but future versions will [2, 3].
>>>>
>>>>- ASMifier is similar to BCELifier. Both ASM and BCEL provide utilities
>>>>to manage type descriptors. ASM does not provide a Class2HTML, but
>>>>provides a package to convert classes to and from XML. ASM does not
>>>>provide pattern matching functions to find instruction sequences that
>>>>match a given pattern.
>>>>
>>>>- ASM verifier is less complete that in BCEL (only pass3b is
>>>>implemented), but there is a framework for code analysis similar to
>>>>bcel.verifier.structurals package.
>>>>
>>>>- Finally ASM is packaged in a more modular way than BCEL, and is more
>>>>compact (due to the fact that (1) some features are not implemented in
>>>>ASM - repository, full verifier, etc [but conversely some ASM features
>>>>are not provided in BCEL: JDK1.5 support], (2) the BCEL DOM like API is
>>>>much more detailled than in ASM, and (3) ASM jars are optimized - no
>>>>debug info, private member names changed to shorter names, optimized
>>>>constant pool):
>>>>
>>>> ASM 2.0 BCEL 5.1 (jar sizes in KB)
>>>>SAX like API only 33 N/A
>>>>+DOM like API 49 321
>>>>+verifier 67 449
>>>>+utils 97 485
>>>>+html/xml util 145 504
>>>>
>>>>Eric (ASM project leader)
>>>>
>>>>[1]
>>>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
>>>>/%3c8103E8A9D484EB4280806F701E3FE6D1038C98D2@svexmb02.merc-int.com%3e
>>>>[2]
>>>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
>>>>/%3c31cc373604121319355782fad5@mail.gmail.com%3e
>>>>[3]
>>>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
>>>>/%3c31cc3736050131091856624204@mail.gmail.com%3e
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>
>>--
>>You receive this message as a subscriber of the asm@objectweb.org mailing list.
>>To unsubscribe: mailto:asm-unsubscribe@objectweb.org
>>For general help: mailto:sympa@objectweb.org?subject=help
>>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>
>>
>>
>>
>>
>
>
>
>------------------------------------------------------------------------
>
>
>
>
Re: [asm] Re: comparison between BCEL and ASM
Posted by Alexandre Vasseur <av...@gmail.com>.
ASM just rocks. We have implemented AspectWerkz with BCEL, with
Javassist, and with ASM in the last 2 years, going from AspectWerkz
0.x to 2.x
ASM programming model is by far easier than the BCEL one. The memory
footprint is much smaller as well, especially because there is no
"Repository" in ASM and thus it is really pay as you go.
Aside, from what we experienced in AspectWerkz, the BCEL so called
Repository is just broken when you have some classloader hierarchies
and multi threaded instrumentation. We ended up in writting our own
hack for that. With ASM, we implemented our own repository, that does
not suffer from that weakness:
http://svn.apache.org/viewcvs.cgi/jakarta/bcel/trunk/src/java/org/apache/bcel/Repository.java?rev=152903&view=markup
This class contains only static methods, so you have to carrully avoid
using it (and any variant like ClassLoaderRepository) since f.e. when
doing on the fly instrumentation, it is obvious that 2 threads can do
instrumentation for 2 different classloader.
ASM support for Java 5 annotation is really great, especially in 2.x,
and it has been in since the early beta of Java 5, which is really
important. This is fairly easy to have in BCEL, and f.e. is done in
AspectJ (that is unfortunately still using BCEL, and even worse we
have a modified version to have a much more lazy behavior) but that s
obviously something you want to avoid to deal with.
We implemented the whole AspectWerkz with only the "SAX" style of ASM.
This proves it is possible to do fairly advanced transformation (yes
sometime we do some lookahead visit, but only when we need those. In
bcel, I would end up in iterating this memory expensive instruction
list, going back and forth, and the resulting code will actually be
much harder to understand and maintain).
Alex
PS: not sure if it will reach BCEL lists since I am not subscribed
there anymore.
On 5/3/05, Eugene Kuleshov <eu...@md.pp.ru> 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.
>
> ASM's verifier is actually provide a bytecode-level verification and
> does not do type and signature checking, primarily because you'll have
> to have some kind of class repository for this. Anyway, it is quite easy
> to implement but I doubt that it will be really useful, because you can
> always actually load class using VM classloader in order to perform such
> validation.
>
> regards,
> Eugene
>
> Henri Yandell wrote:
> > Nice email, thanks.
> >
> > For the areas where BCEL has features that ASM does not (fuller DOM,
> > full verifier) does ASM have plans in the works to support these at
> > some point, or are they outside of the ASM philosophy?
> >
> > Hen
> >
> > On 3/22/05, BRUNETON Eric RD-MAPS-GRE <er...@francetelecom.com> wrote:
> >
> >>Paul McLachlan wrote (14 Dec 2004) [1]:
> >>
> >>>>Or a response from a BCEL developer to indicate what BCEL offers that
> >>>>ASM lacks would be useful...
> >>>
> >>>FWIW, I looked at ASM a few months ago to see if I wanted to migrate to
> >>
> >>>it and decided it didn't have the features I needed. I think, at the
> >>>time, I compared the two to the difference between SAX and DOM.
> >>>Sometimes you can do what you want with SAX, and it's faster. But
> >>>sometimes, you really need DOM and are willing to pay for it.
> >>>I'm in (and will always be in, with our problemspace) the latter
> >>>camp, as far as bytecode transformation goes.
> >>
> >>The comparison with SAX and DOM is not true: both ASM and BCEL provide a
> >>SAX and a DOM like API. For ASM the SAX like API is in asm package, and
> >>the DOM like API in asm.tree package. For BCEL the SAX like API is the
> >>classfile.Visitor and generic.Visitor interfaces and the DOM like API is
> >>the classes of the classfile and generic packages. The *real* difference
> >>is that in ASM the DOM like API is provided on top of the SAX like API,
> >>while in BCEL the converse is true. It is therefore possible, with ASM,
> >>to use the SAX like API without paying the cost of DOM, which is not
> >>possible with BCEL. Note also that the cost of the DOM like API of ASM
> >>is much lower than in BCEL:
> >>
> >>time to load some 1240 classes with JDK1.5: T = ~0.94 s
> >>time to load these classes with a simple on the fly transformation:
> >>- with ASM 2.0 SAX like API: ~1.5 s (= +60% compared to T)
> >>- with ASM 2.0 DOM like API: ~1.84 s (= +95% compared to T)
> >>- with BCEL 5.1 DOM like API: ~6.9 s (= +630% compared to T)
> >>
> >>Some other differences and similarities between ASM 2.0 and BCEL 5.1 I
> >>can think of are:
> >>
> >>- ASM completely hides the constant pool in order to provide a simpler
> >>API. The drawback is that it is not possible to implement
> >>transformations that need to explicitely manipulate the constant pool
> >>(for example to sort the constants in order to get better jar
> >>compression ratios; in fact it is possible, but more code is required)
> >>
> >>- ASM does not provide any equivalent for Repository (but there are
> >>suggestions to remove this from BCEL [3]), nor any classloader related
> >>utilities
> >>
> >>- Both ASM and BCEL provide functions to compute maxstacksize and
> >>maxlocals, transparently handle the "wide" opcode, and transparently
> >>change goto and jsr to goto_w and jsr_w when needed. ASM also
> >>transparently change if instructions to if+goto_w instructions when
> >>needed, which is not done in BCEL (I think).
> >>
> >>- Both ASM and BCEL allow "lazy" parsing of class files. In BCEL this is
> >>done with the JavaClass/ClassGen distinction, in ASM by the fact that
> >>returning null in visitField or visitMethod skips the parsing of a field
> >>or method.
> >>
> >>- ASM provides support for JDK1.5 class attributes, including an API to
> >>analyze/transform/generate generic signatures. BCEL 5.1 does not provide
> >>this, but future versions will [2, 3].
> >>
> >>- ASMifier is similar to BCELifier. Both ASM and BCEL provide utilities
> >>to manage type descriptors. ASM does not provide a Class2HTML, but
> >>provides a package to convert classes to and from XML. ASM does not
> >>provide pattern matching functions to find instruction sequences that
> >>match a given pattern.
> >>
> >>- ASM verifier is less complete that in BCEL (only pass3b is
> >>implemented), but there is a framework for code analysis similar to
> >>bcel.verifier.structurals package.
> >>
> >>- Finally ASM is packaged in a more modular way than BCEL, and is more
> >>compact (due to the fact that (1) some features are not implemented in
> >>ASM - repository, full verifier, etc [but conversely some ASM features
> >>are not provided in BCEL: JDK1.5 support], (2) the BCEL DOM like API is
> >>much more detailled than in ASM, and (3) ASM jars are optimized - no
> >>debug info, private member names changed to shorter names, optimized
> >>constant pool):
> >>
> >> ASM 2.0 BCEL 5.1 (jar sizes in KB)
> >>SAX like API only 33 N/A
> >>+DOM like API 49 321
> >>+verifier 67 449
> >>+utils 97 485
> >>+html/xml util 145 504
> >>
> >>Eric (ASM project leader)
> >>
> >>[1]
> >>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
> >>/%3c8103E8A9D484EB4280806F701E3FE6D1038C98D2@svexmb02.merc-int.com%3e
> >>[2]
> >>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
> >>/%3c31cc373604121319355782fad5@mail.gmail.com%3e
> >>[3]
> >>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
> >>/%3c31cc3736050131091856624204@mail.gmail.com%3e
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
> >>
> >>
>
>
>
> --
> You receive this message as a subscriber of the asm@objectweb.org mailing list.
> To unsubscribe: mailto:asm-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Eugene Kuleshov <eu...@md.pp.ru>.
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.
ASM's verifier is actually provide a bytecode-level verification and
does not do type and signature checking, primarily because you'll have
to have some kind of class repository for this. Anyway, it is quite easy
to implement but I doubt that it will be really useful, because you can
always actually load class using VM classloader in order to perform such
validation.
regards,
Eugene
Henri Yandell wrote:
> Nice email, thanks.
>
> For the areas where BCEL has features that ASM does not (fuller DOM,
> full verifier) does ASM have plans in the works to support these at
> some point, or are they outside of the ASM philosophy?
>
> Hen
>
> On 3/22/05, BRUNETON Eric RD-MAPS-GRE <er...@francetelecom.com> wrote:
>
>>Paul McLachlan wrote (14 Dec 2004) [1]:
>>
>>>>Or a response from a BCEL developer to indicate what BCEL offers that
>>>>ASM lacks would be useful...
>>>
>>>FWIW, I looked at ASM a few months ago to see if I wanted to migrate to
>>
>>>it and decided it didn't have the features I needed. I think, at the
>>>time, I compared the two to the difference between SAX and DOM.
>>>Sometimes you can do what you want with SAX, and it's faster. But
>>>sometimes, you really need DOM and are willing to pay for it.
>>>I'm in (and will always be in, with our problemspace) the latter
>>>camp, as far as bytecode transformation goes.
>>
>>The comparison with SAX and DOM is not true: both ASM and BCEL provide a
>>SAX and a DOM like API. For ASM the SAX like API is in asm package, and
>>the DOM like API in asm.tree package. For BCEL the SAX like API is the
>>classfile.Visitor and generic.Visitor interfaces and the DOM like API is
>>the classes of the classfile and generic packages. The *real* difference
>>is that in ASM the DOM like API is provided on top of the SAX like API,
>>while in BCEL the converse is true. It is therefore possible, with ASM,
>>to use the SAX like API without paying the cost of DOM, which is not
>>possible with BCEL. Note also that the cost of the DOM like API of ASM
>>is much lower than in BCEL:
>>
>>time to load some 1240 classes with JDK1.5: T = ~0.94 s
>>time to load these classes with a simple on the fly transformation:
>>- with ASM 2.0 SAX like API: ~1.5 s (= +60% compared to T)
>>- with ASM 2.0 DOM like API: ~1.84 s (= +95% compared to T)
>>- with BCEL 5.1 DOM like API: ~6.9 s (= +630% compared to T)
>>
>>Some other differences and similarities between ASM 2.0 and BCEL 5.1 I
>>can think of are:
>>
>>- ASM completely hides the constant pool in order to provide a simpler
>>API. The drawback is that it is not possible to implement
>>transformations that need to explicitely manipulate the constant pool
>>(for example to sort the constants in order to get better jar
>>compression ratios; in fact it is possible, but more code is required)
>>
>>- ASM does not provide any equivalent for Repository (but there are
>>suggestions to remove this from BCEL [3]), nor any classloader related
>>utilities
>>
>>- Both ASM and BCEL provide functions to compute maxstacksize and
>>maxlocals, transparently handle the "wide" opcode, and transparently
>>change goto and jsr to goto_w and jsr_w when needed. ASM also
>>transparently change if instructions to if+goto_w instructions when
>>needed, which is not done in BCEL (I think).
>>
>>- Both ASM and BCEL allow "lazy" parsing of class files. In BCEL this is
>>done with the JavaClass/ClassGen distinction, in ASM by the fact that
>>returning null in visitField or visitMethod skips the parsing of a field
>>or method.
>>
>>- ASM provides support for JDK1.5 class attributes, including an API to
>>analyze/transform/generate generic signatures. BCEL 5.1 does not provide
>>this, but future versions will [2, 3].
>>
>>- ASMifier is similar to BCELifier. Both ASM and BCEL provide utilities
>>to manage type descriptors. ASM does not provide a Class2HTML, but
>>provides a package to convert classes to and from XML. ASM does not
>>provide pattern matching functions to find instruction sequences that
>>match a given pattern.
>>
>>- ASM verifier is less complete that in BCEL (only pass3b is
>>implemented), but there is a framework for code analysis similar to
>>bcel.verifier.structurals package.
>>
>>- Finally ASM is packaged in a more modular way than BCEL, and is more
>>compact (due to the fact that (1) some features are not implemented in
>>ASM - repository, full verifier, etc [but conversely some ASM features
>>are not provided in BCEL: JDK1.5 support], (2) the BCEL DOM like API is
>>much more detailled than in ASM, and (3) ASM jars are optimized - no
>>debug info, private member names changed to shorter names, optimized
>>constant pool):
>>
>> ASM 2.0 BCEL 5.1 (jar sizes in KB)
>>SAX like API only 33 N/A
>>+DOM like API 49 321
>>+verifier 67 449
>>+utils 97 485
>>+html/xml util 145 504
>>
>>Eric (ASM project leader)
>>
>>[1]
>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
>>/%3c8103E8A9D484EB4280806F701E3FE6D1038C98D2@svexmb02.merc-int.com%3e
>>[2]
>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
>>/%3c31cc373604121319355782fad5@mail.gmail.com%3e
>>[3]
>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
>>/%3c31cc3736050131091856624204@mail.gmail.com%3e
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: comparison between BCEL and ASM
Posted by Henri Yandell <fl...@gmail.com>.
Nice email, thanks.
For the areas where BCEL has features that ASM does not (fuller DOM,
full verifier) does ASM have plans in the works to support these at
some point, or are they outside of the ASM philosophy?
Hen
On 3/22/05, BRUNETON Eric RD-MAPS-GRE <er...@francetelecom.com> wrote:
> Paul McLachlan wrote (14 Dec 2004) [1]:
> >> Or a response from a BCEL developer to indicate what BCEL offers that
> >> ASM lacks would be useful...
> >
> >FWIW, I looked at ASM a few months ago to see if I wanted to migrate to
>
> >it and decided it didn't have the features I needed. I think, at the
> >time, I compared the two to the difference between SAX and DOM.
> >Sometimes you can do what you want with SAX, and it's faster. But
> >sometimes, you really need DOM and are willing to pay for it.
> >I'm in (and will always be in, with our problemspace) the latter
> >camp, as far as bytecode transformation goes.
>
> The comparison with SAX and DOM is not true: both ASM and BCEL provide a
> SAX and a DOM like API. For ASM the SAX like API is in asm package, and
> the DOM like API in asm.tree package. For BCEL the SAX like API is the
> classfile.Visitor and generic.Visitor interfaces and the DOM like API is
> the classes of the classfile and generic packages. The *real* difference
> is that in ASM the DOM like API is provided on top of the SAX like API,
> while in BCEL the converse is true. It is therefore possible, with ASM,
> to use the SAX like API without paying the cost of DOM, which is not
> possible with BCEL. Note also that the cost of the DOM like API of ASM
> is much lower than in BCEL:
>
> time to load some 1240 classes with JDK1.5: T = ~0.94 s
> time to load these classes with a simple on the fly transformation:
> - with ASM 2.0 SAX like API: ~1.5 s (= +60% compared to T)
> - with ASM 2.0 DOM like API: ~1.84 s (= +95% compared to T)
> - with BCEL 5.1 DOM like API: ~6.9 s (= +630% compared to T)
>
> Some other differences and similarities between ASM 2.0 and BCEL 5.1 I
> can think of are:
>
> - ASM completely hides the constant pool in order to provide a simpler
> API. The drawback is that it is not possible to implement
> transformations that need to explicitely manipulate the constant pool
> (for example to sort the constants in order to get better jar
> compression ratios; in fact it is possible, but more code is required)
>
> - ASM does not provide any equivalent for Repository (but there are
> suggestions to remove this from BCEL [3]), nor any classloader related
> utilities
>
> - Both ASM and BCEL provide functions to compute maxstacksize and
> maxlocals, transparently handle the "wide" opcode, and transparently
> change goto and jsr to goto_w and jsr_w when needed. ASM also
> transparently change if instructions to if+goto_w instructions when
> needed, which is not done in BCEL (I think).
>
> - Both ASM and BCEL allow "lazy" parsing of class files. In BCEL this is
> done with the JavaClass/ClassGen distinction, in ASM by the fact that
> returning null in visitField or visitMethod skips the parsing of a field
> or method.
>
> - ASM provides support for JDK1.5 class attributes, including an API to
> analyze/transform/generate generic signatures. BCEL 5.1 does not provide
> this, but future versions will [2, 3].
>
> - ASMifier is similar to BCELifier. Both ASM and BCEL provide utilities
> to manage type descriptors. ASM does not provide a Class2HTML, but
> provides a package to convert classes to and from XML. ASM does not
> provide pattern matching functions to find instruction sequences that
> match a given pattern.
>
> - ASM verifier is less complete that in BCEL (only pass3b is
> implemented), but there is a framework for code analysis similar to
> bcel.verifier.structurals package.
>
> - Finally ASM is packaged in a more modular way than BCEL, and is more
> compact (due to the fact that (1) some features are not implemented in
> ASM - repository, full verifier, etc [but conversely some ASM features
> are not provided in BCEL: JDK1.5 support], (2) the BCEL DOM like API is
> much more detailled than in ASM, and (3) ASM jars are optimized - no
> debug info, private member names changed to shorter names, optimized
> constant pool):
>
> ASM 2.0 BCEL 5.1 (jar sizes in KB)
> SAX like API only 33 N/A
> +DOM like API 49 321
> +verifier 67 449
> +utils 97 485
> +html/xml util 145 504
>
> Eric (ASM project leader)
>
> [1]
> http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
> /%3c8103E8A9D484EB4280806F701E3FE6D1038C98D2@svexmb02.merc-int.com%3e
> [2]
> http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
> /%3c31cc373604121319355782fad5@mail.gmail.com%3e
> [3]
> http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
> /%3c31cc3736050131091856624204@mail.gmail.com%3e
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org