Would anybody be interested in swapping the byte code library with BCEL (http://jakarta.apache.org/bcel/)? I have used both byte code libraries, and BCEL seems to be more featureful and easier to use. Switching would also mean that we wouldn't have to maintain our own byte-code library as Java releases add more features.
Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wouldn't call the current bytecode API in EMMA a "library" (except maybe for my pesonal projects), but if I were to swap it for one it probably wouldn't be BCEL. My first candidate would be ASM (http://asm.objectweb.org/). (BCEL has a reputation for being slow and EMMA pays much attention to speed).
ASM does not create first class objects for every instruction like BCEL does (AFAIK) and uses a Visitor-like approach to processing. The latter is very convenient conceptually. EMMA's approach is somewhat half-way between BCEL and ASM: first class objects for things like classes, methods, constant pool, etc but a lower-level pool visit loop for individual opcodes. In the early prototypes the loop used true visit methods and was later "inlined" for speed.
Someone would have to give me some proof data that the instrumentation speed could be kept up if such a switch is performed. It does not have to require the actual codebase switch: we could architect some apples-to-apples comparison between EMMA and jcoverage, for example (attention needs to be pais to the fact that jcoverage injects bytecode per source line, I believe, and not per basic block).
Vlad.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would anybody be interested in swapping the byte code library with BCEL (http://jakarta.apache.org/bcel/)? I have used both byte code libraries, and BCEL seems to be more featureful and easier to use. Switching would also mean that we wouldn't have to maintain our own byte-code library as Java releases add more features.
Ryan
I wouldn't call the current bytecode API in EMMA a "library" (except maybe for my pesonal projects), but if I were to swap it for one it probably wouldn't be BCEL. My first candidate would be ASM (http://asm.objectweb.org/). (BCEL has a reputation for being slow and EMMA pays much attention to speed).
ASM does not create first class objects for every instruction like BCEL does (AFAIK) and uses a Visitor-like approach to processing. The latter is very convenient conceptually. EMMA's approach is somewhat half-way between BCEL and ASM: first class objects for things like classes, methods, constant pool, etc but a lower-level pool visit loop for individual opcodes. In the early prototypes the loop used true visit methods and was later "inlined" for speed.
Someone would have to give me some proof data that the instrumentation speed could be kept up if such a switch is performed. It does not have to require the actual codebase switch: we could architect some apples-to-apples comparison between EMMA and jcoverage, for example (attention needs to be pais to the fact that jcoverage injects bytecode per source line, I believe, and not per basic block).
Vlad.
Those are valid reasons for not using BCEL, I will look at ASM and see if I can come up with a patch.
Ryan
In the current RFE list, this is definitely not high priority.