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] [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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
