Re: Re: comparison between BCEL and ASM

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 <[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.
>>
>>  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 <[email protected]> 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
>>>>/%[email protected]%3e
>>>>[2]
>>>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox
>>>>/%[email protected]%3e
>>>>[3]
>>>>http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox
>>>>/%[email protected]%3e
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [email protected]
>>>>For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>        
>>>>
>>
>>--
>>You receive this message as a subscriber of the [email protected] mailing list.
>>To unsubscribe: mailto:[email protected]
>>For general help: mailto:[email protected]?subject=help
>>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>
>>
>>
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>
>  
>