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 thatFWIW, I looked at ASM a few months ago to see if I wanted to migrate to
ASM lacks would be useful...
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] [2] http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200412.mbox /[EMAIL PROTECTED] [3] http://mail-archives.eu.apache.org/mod_mbox/jakarta-bcel-dev/200501.mbox /[EMAIL PROTECTED]
--------------------------------------------------------------------- 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] ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
------------------------------------------------------------------------
