As I wrote in my posting to this thread https://sourceforge.net/forum/forum.php?thread_id=1090808&forum_id=373865 I encounterd problems with the byte code enhancer of my database. Additionally I raised the general question about how to deal with other byte code enhancers. AspectJ, JDO enhancers, etc.
I solved my problem by just first instrument with EMMA after the build and then enhance the already instrumented classes with my database tool. This also caused that EMMA doesn't report anymore on the methods added by the enhancer which really screwed up my reports. While this can be desirable with AspectJ for instance...
Did anybody ran into similar problems? Which byte code enhancers run smoothly with EMMA and in which order? Byte code enhancers are sometimes really a curse *sigh*
Greetings
/olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, bytecode enhancers might be a "curse" but they can also be very fast, which is why I like this approach. And what about running multiple source code enhancers at the same time? I can easily see that it would be even worse.
It is possible that EMMA will evolve into a tool that can do both source and byte code instrumentation, but this is not the short term future plan (source code parsing is slow).
Note that Java bytecode format is extentible and there is no reason why two or more bytecode tools couldn't agree on a set of custom .class attributes that help them co-exist. For example, right now EMMA automatically excludes auto-generated methods that are marked with Synthetic or Bridge attribute. Moreover, if it needs to add a method itself it will mark it Synthetic to stay consistent with its own approach. If all other tools followed this way of doing it life would be much easier.
The problem is every such tool assumes it is the only tool the end user is using. 3-4 years ago when I did my first bytecode experimentation it was a very esoteric topic. Now it is becoming a standard technique and I am sure eventually new standards could be developed for bytecode tool cooperation (a new JSR, anyone? :)
I am hoping the new Java 1.5 metadata feature will be useful for EMMA, although I don't think it will help with marking code at the level more granular than methods.
Anyway, that's my opinion anyway. I know there are other coverage tools on the market that are based on bytecode instrumentation (and they have to face the same issues) and I don't see why EMMA couldn't be a very decent (and free) contender to them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I wrote in my posting to this thread https://sourceforge.net/forum/forum.php?thread_id=1090808&forum_id=373865 I encounterd problems with the byte code enhancer of my database. Additionally I raised the general question about how to deal with other byte code enhancers. AspectJ, JDO enhancers, etc.
I solved my problem by just first instrument with EMMA after the build and then enhance the already instrumented classes with my database tool. This also caused that EMMA doesn't report anymore on the methods added by the enhancer which really screwed up my reports. While this can be desirable with AspectJ for instance...
Did anybody ran into similar problems? Which byte code enhancers run smoothly with EMMA and in which order? Byte code enhancers are sometimes really a curse *sigh*
Greetings
/olaf
Yes, bytecode enhancers might be a "curse" but they can also be very fast, which is why I like this approach. And what about running multiple source code enhancers at the same time? I can easily see that it would be even worse.
It is possible that EMMA will evolve into a tool that can do both source and byte code instrumentation, but this is not the short term future plan (source code parsing is slow).
Note that Java bytecode format is extentible and there is no reason why two or more bytecode tools couldn't agree on a set of custom .class attributes that help them co-exist. For example, right now EMMA automatically excludes auto-generated methods that are marked with Synthetic or Bridge attribute. Moreover, if it needs to add a method itself it will mark it Synthetic to stay consistent with its own approach. If all other tools followed this way of doing it life would be much easier.
The problem is every such tool assumes it is the only tool the end user is using. 3-4 years ago when I did my first bytecode experimentation it was a very esoteric topic. Now it is becoming a standard technique and I am sure eventually new standards could be developed for bytecode tool cooperation (a new JSR, anyone? :)
I am hoping the new Java 1.5 metadata feature will be useful for EMMA, although I don't think it will help with marking code at the level more granular than methods.
Anyway, that's my opinion anyway. I know there are other coverage tools on the market that are based on bytecode instrumentation (and they have to face the same issues) and I don't see why EMMA couldn't be a very decent (and free) contender to them.