#65 Support line coverage where possible

[Chris Nappin]

If any class files don't include "full debug
information" then EMMA disables line coverage on all
classes.

Surely it should merely disabled line coverage on
classes that don't include "full debug information",
and provide as much detail as it can on the rest of the
classes?

I'm trying to find a code coverage tool that can cope
with code that includes AspectJ-weaved classes. The
AspectJ weaver introduces "artifical" code to classes,
but does not generate "full debug information"
(especially line numbers) on such "artifical" code.
Hence EMMA barfs on such class files.

I have raised this to the AspectJ team but they are
reluctant to generate such "artifical" debug information.

In the mean time I'm yet to find a code coverage tool
that will cope well with AspectJ. I have tried most of
the Open Source solutions available at the moment and
none cope well.

Thanks,

Chris Nappin.

[Vlad Roubtsov]

Logged In: YES
user_id=1013207

The correct way to use EMMA with bytecode enhancers that do
not correctly preserve debug data is to use EMMA ahead of
them in the overall tool chain.

If this solution is not acceptable, then you need to
articulate what it would be for a coverage tool to "cope"
with AspectJ-weaved classes or a similar situation.

You may have noticed that EMMA coverage reports rely on
being able to roll up coverage stats at various levels (all,
package, class, etc). Such aggregate information is
essential for users to be able to drill down into a coverage
situation for a large codebase. How do you propose to
calculate such rollups if information is not available for
some classes?

[Chris Nappin]

Logged In: YES
user_id=257104

Hi,

Thanks for the response. I'm using the AspectJ compiler to
compile all Java and AspectJ source code, so there is no
earlier step in the chain that EMMA could use?

It's not that AspectJ doesn't preserve debug data, rather it
only produces a limited amount for any aspect-based code.

What I'd ideally like is that EMMA can cope with a class
file with a "partial" line number table, reporting coverage
where it can and ignoring the rest.

The total line-based coverage for a given class could then
be based on how many lines that have line numbers that have
been tested, so such "artificial" lines don't count for or
against coverage. Do you think that might work?

Cheers,

Chris Nappin.

[Vlad Roubtsov]

Logged In: YES
user_id=1013207

I am wondering whether the LineNumberTable attribute can
support the flexibility that you are asking for.

This attribute is a list of pairs, with each pair
associating a bytecode offset and a line number within the
source file. Because only the start of a bytecode block is
recorded in each pair, one has to make the assumption that
a piece of bytecode maps to a certain source file line until
another pair overrides the mapping for the current bytecode
offset. This format does not support the notion of
"unmapped holes".

Not being an AspectJ user, I don't know how well AspectJ can
leverage this attribute. They should be able to, because the
.class format spec is (somewhat) language-independent.
However, they may not feel like spending the effort.

Have you been able to, say, step through AspectJ-enhanced
classes in a debugger? Or do you think Aspect-J preserves
line number info in exception stack traces? Those kinds of
things would be evidence that they did something proper with
line number mappings.

[SourceForge Robot]

Logged In: YES
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 13 days (the time period specified by
the administrator of this Tracker).