Bytecode generation, Source code mappings, JCov, Future

[Uday Dhanikonda]

Alex

There was an effort by Robert recently to rewrite JCov using JVM TI.

Robert can you comment on this.

Thanks
Uday

Alex Rau wrote:
> Hi all,
>
> I've searched the web and asked at forum.sun.com but my answer 
> regarding the javac compiler couldn't be answered yet. so here we go 
> with a rational first:
>
> Rational: I'd like to achieve the following: The byte code created 
> with javac should not only contain line number information in debug 
> mode, but additionally I want to track exactly which statement 
> (including column information as there can be multiple statements in 
> one source code line) leads to a certain bytecode instruction or a set 
> of instructions. I strongly need this kind of functionality in javac 
> as the project I'm working on is settled in the testing area (mutation 
> testing in java on bytecode level  which you can imagine as some kind 
> of (beta) code coverage software with a different and IMHO superior 
> technique - http://retroduction.org for more details if you are 
> interested). The software must be able to report mutated *statements* 
> which means that line informations are insufficient.
>
> My Question is: in older JDK's there was something called JCov which 
> enhanced byte code with additional information regarding which 
> statements finally led to a/multiple bytecode instruction(s). I 
> stumbled upon this while debugging javac when I wanted to learn it's 
> design/code. I think it's mostly what I need - however the JCov switch 
> is a hidden feature. It was "more" public in JDK 1.2 and was pretended 
> to have been ported to the JVMPI interface later. However I did not 
> find where the port should have been integrated - I'm no JVMPI (and 
> JVMTI) guru. Honestly I doubt that something similar is in the 
> JVM(P/T)I toolset...
>
> So perhaps someone has more knowledge about JCov and what happened to 
> it. Furthermore I'd like to push a discussion on whether this would be 
> a candidate for the kitchen sink (no JLS changes, just internal) with 
> the goal to implement the above described functionality *including a 
> supported and public interface* (not a hidden feature anymore). The 
> first benefit could then obviously be that javac could be mutation 
> tested ;) Furthermore other Java developers would have solid 
> information and documentation about this API instead of relying on 
> mostly unknown and hidden features.
>
> Best Regards,
>
>  Alex
>