CodeTools proposal: "JCov"

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Feb 26 14:36:47 PST 2014


Kevin,

Thanks for posting this.

I also note that support for JCov is already built into jtreg[1]. Making 
jcov available on OpenJDK will allow us to expose the functionality in 
jtreg.

I also note that JCov has support for reporting the coverage of new code 
in (the patch for) a changeset.

-- Jon

[1] http://openjdk.java.net/jtreg

On 02/26/2014 02:21 PM, Kevin Looney wrote:
> Name: JCov
>
> Summary: A code coverage tools, used to measure test coverage on the 
> Java platform.
>
> Proposed by: Kevin Looney
>
> Rationale:
>
> This proposal is to open the JCov code coverage tool into the 
> CodeTools project of OpenJDK. The goal is to provide transparency to 
> the process of gathering coverage metrics during OpenJDK regression 
> testing.
>
> The main motivation is transparency for test coverage metrics. The 
> advantage to promoting standard coverage based on JCov is that JDK 
> developers will be able to use a code coverage tool that stays in 
> 'lock step' with Java language and VM developments.
>
> JCov (Java code COVerage) is a pure Java implementation of a code 
> coverage tool which provides a means to measure and analyze dynamic 
> code coverage of Java programs. JCov provides functionality to collect 
> method, linear block and branch coverage, as well as showing uncovered 
> execution paths.
>
> Jcov is also able to show a program's source code annotated with 
> coverage information. It also has features to report on the modified 
> lines in a changeset. This makes it attractive to incorporate into the 
> OpenJDK code review process.
>
> From a testing perspective, JCov is most useful to determine execution 
> paths (in a Java application) that a test suite is (or is not) executing.
>
> JCov supports applications on JDK 1.0 and higher (including JDK 8), 
> CDC/CLDC 1.0 and higher, and JavaCard 3.0 and higher.
>
> Other open source Java code coverage tools exist.  They are typically 
> not suitable because:
>
> a.) they do not support the current level of the JDK for which 
> coverage is being gathered
>
> b.) they do not provide instrumentation to support the coverage of the 
> JDK itself.
>
> c.) they do not provide a method to gather coverage data from a device 
> across a network.
>
> d.) they do not provide a method to aggregate coverage collections 
> from concurrent JVMs.
>



More information about the code-tools-dev mailing list