From dalibor.topic at oracle.com Thu Feb 8 10:12:25 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 8 Feb 2018 11:12:25 +0100 Subject: FW: Jcov: Can JCov provide test/coverage reports for Native Java classes eg java.lang.String? In-Reply-To: References: Message-ID: Hi Jeffrey, The JCov tool is part of the Code Tools Project. As indicated on http://openjdk.java.net/projects/code-tools/ the mailing list for that tool is jcov-dev [0]. I have bcc:ed members@ and forwarded your e-mail to jcov-dev@ - please subscribe at [0] in order to be able to follow the thread and reply. cheers, dalibor topic [0] http://mail.openjdk.java.net/mailman/listinfo/jcov-dev On 08.02.2018 06:43, ?????? ??????? wrote: > To: JDK Tools Members, > I would greatly appreciate your thoughts on this: > Can JCov provide test/coverage reports for Native Java classes eg java.lang.String? > I wanted to demonstrate the effectiveness of JCov to a Japanese audience by generating a coverage report on Native Classes, for example java.lang.String. In other words, a way to generate coverage reports on Junit test classes for Native Java Class. Is that possible? > I also want to do this on Java1.4 using Junit3 and Java8 using Junit4 and then compare coverage reports. From the online documentation I am a little confused if Java1.4 is supported: > https://wiki.openjdk.java.net/display/CodeTools/How+To+Build+JCov Requirements: JDK version 5.0 > https://wiki.openjdk.java.net/display/CodeTools/jcov JCov supports applications on JDK 1.0 and higher (including JDK 8) > I am struggling to find a coverage tool that can accomplish this. Is JCov the potential tool? > I would really appreciate any response that can help me move forward. > Many thanks in advance, > Jeff > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From jonathan.gibbons at oracle.com Fri Feb 9 00:17:09 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 8 Feb 2018 16:17:09 -0800 Subject: FW: Jcov: Can JCov provide test/coverage reports for Native Java classes eg java.lang.String? In-Reply-To: References: Message-ID: <47796658-a841-5edd-1b0c-fa2e6e88f04c@oracle.com> Jeffrey, JCov cannot instrument native code, -- Jon On 2/8/18 2:12 AM, dalibor topic wrote: > Hi Jeffrey, > > The JCov tool is part of the Code Tools Project. As indicated on > http://openjdk.java.net/projects/code-tools/ the mailing list for that > tool is jcov-dev [0]. > > I have bcc:ed members@ and forwarded your e-mail to jcov-dev@ - please > subscribe at [0] in order to be able to follow the thread and reply. > > cheers, > dalibor topic > > [0] http://mail.openjdk.java.net/mailman/listinfo/jcov-dev > > On 08.02.2018 06:43, ?????? ??????? wrote: >> To: JDK Tools Members, >> I would greatly appreciate your thoughts on this: >> Can JCov provide test/coverage reports for Native Java classes eg >> java.lang.String? >> I wanted to demonstrate the effectiveness of JCov to a Japanese >> audience by generating a coverage report on Native Classes, for >> example java.lang.String. In other words, a way to generate coverage >> reports on Junit test classes for Native Java Class. Is that possible? >> I also want to do this on Java1.4 using Junit3 and Java8 using Junit4 >> and then compare coverage reports. From the online documentation I am >> a little confused if Java1.4 is supported: >> https://wiki.openjdk.java.net/display/CodeTools/How+To+Build+JCov >> Requirements: JDK version 5.0 >> https://wiki.openjdk.java.net/display/CodeTools/jcov?? JCov supports >> applications on JDK 1.0 and higher (including JDK 8) >> I am struggling to find a coverage tool that can accomplish this. Is >> JCov the potential tool? >> I would really appreciate any response that can help me move forward. >> Many thanks in advance, >> Jeff >> > From alexey.fedorchenko at oracle.com Fri Feb 9 07:50:44 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Thu, 8 Feb 2018 23:50:44 -0800 Subject: Jcov: Can JCov provide test/coverage reports for Native Java classes eg java.lang.String? In-Reply-To: <47796658-a841-5edd-1b0c-fa2e6e88f04c@oracle.com> References: <47796658-a841-5edd-1b0c-fa2e6e88f04c@oracle.com> Message-ID: <697DB406-0104-4C20-8C24-31252EF8FE3C@oracle.com> Hello! JCov works with java bytecode and your example should be possible for the java.lang.String class file. You will need to change JCov build to produce custom binaries version for the 1.4 JDK. (you need to compile jcov_network_saver.jar/jcov_file_saver.jar for the correct target. for the JDK5 it is simply changing the target in the build.xml for savers jars, for the 1.4 - small changes will be required in savers? source code). ?Alexey > On Feb 8, 2018, at 4:17 PM, Jonathan Gibbons wrote: > > Jeffrey, > > JCov cannot instrument native code, > > -- Jon > > > On 2/8/18 2:12 AM, dalibor topic wrote: >> Hi Jeffrey, >> >> The JCov tool is part of the Code Tools Project. As indicated on http://openjdk.java.net/projects/code-tools/ the mailing list for that tool is jcov-dev [0]. >> >> I have bcc:ed members@ and forwarded your e-mail to jcov-dev@ - please subscribe at [0] in order to be able to follow the thread and reply. >> >> cheers, >> dalibor topic >> >> [0] http://mail.openjdk.java.net/mailman/listinfo/jcov-dev >> >> On 08.02.2018 06:43, ?????? ??????? wrote: >>> To: JDK Tools Members, >>> I would greatly appreciate your thoughts on this: >>> Can JCov provide test/coverage reports for Native Java classes eg java.lang.String? >>> I wanted to demonstrate the effectiveness of JCov to a Japanese audience by generating a coverage report on Native Classes, for example java.lang.String. In other words, a way to generate coverage reports on Junit test classes for Native Java Class. Is that possible? >>> I also want to do this on Java1.4 using Junit3 and Java8 using Junit4 and then compare coverage reports. From the online documentation I am a little confused if Java1.4 is supported: >>> https://wiki.openjdk.java.net/display/CodeTools/How+To+Build+JCov Requirements: JDK version 5.0 >>> https://wiki.openjdk.java.net/display/CodeTools/jcov JCov supports applications on JDK 1.0 and higher (including JDK 8) >>> I am struggling to find a coverage tool that can accomplish this. Is JCov the potential tool? >>> I would really appreciate any response that can help me move forward. >>> Many thanks in advance, >>> Jeff >>> >> > From jonathan.gibbons at oracle.com Wed Feb 28 17:05:32 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Feb 2018 09:05:32 -0800 Subject: Better jcov integration In-Reply-To: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> Message-ID: <37489267-c6b7-0882-f5af-d90574ebab04@oracle.com> cc: jcov-dev at ojn Hi Eric, Generally, writing reports in other useful formats certainly seems like a good, pragmatic suggestion, although I'll leave it to the JCov team to comment in more detail. -- Jon On 2/28/18 4:42 AM, Eric McCorkle wrote: > Hello everyone, > > I recently found myself needing better integration of jcov into various > build/testing tools, so I did two things. First, I modified the jcov > tool to generate a report in the Cobertura XML format, which is used by > Jenkins and other tools as an input format. While these reports are > inferior in my opinion to the HTML reports jcov generates, they do allow > integration with other tools and CI systems. Therefore, I think > providing this functionality would likely encourage more people to use > jcov over the alternatives. > > I've attached the patch for this modification here, if anyone would like > to review it. > > > I've also mostly wrangled the Maven plugin API to create a plugin for > using jcov in a Maven project (however, there is one remaining issue > with documentation generation that I need to correct before I call the > plugin "finished"). I'm not sure if that would be something that would > be added to codetools, if the group ID should be something like > "org.openjdk", or what else ought to be done about it. I will gladly > contribute the code if there's a desire to adopt it. From alexey.fedorchenko at oracle.com Wed Feb 28 20:20:41 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Wed, 28 Feb 2018 12:20:41 -0800 Subject: Better jcov integration In-Reply-To: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> Message-ID: <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com> Hello, Eric! Thank you for the report. I have added an issue for your request [1]. We will address it, I also think that having more report formats is a good suggestion. A few thoughts about the original problem of adding JCov to CI (Jenkins): - use html publisher plugin to show JCov html report - plot build data with plot plugin to look at the coverage trend for builds ( it will require using grep and sed to get data from overview-summary.html to plot.csv ) - create JCov plugin for Jenkins. The latest item and Maven plugin opens a little bit bigger discussion for Code Tools projects: Could we have tool's plugins sources in tool?s repository? Thank you. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902125 ?Alexey > On Feb 28, 2018, at 4:42 AM, Eric McCorkle wrote: > > Hello everyone, > > I recently found myself needing better integration of jcov into various > build/testing tools, so I did two things. First, I modified the jcov > tool to generate a report in the Cobertura XML format, which is used by > Jenkins and other tools as an input format. While these reports are > inferior in my opinion to the HTML reports jcov generates, they do allow > integration with other tools and CI systems. Therefore, I think > providing this functionality would likely encourage more people to use > jcov over the alternatives. > > I've attached the patch for this modification here, if anyone would like > to review it. > > > I've also mostly wrangled the Maven plugin API to create a plugin for > using jcov in a Maven project (however, there is one remaining issue > with documentation generation that I need to correct before I call the > plugin "finished"). I'm not sure if that would be something that would > be added to codetools, if the group ID should be something like > "org.openjdk", or what else ought to be done about it. I will gladly > contribute the code if there's a desire to adopt it. > From jonathan.gibbons at oracle.com Wed Feb 28 21:03:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Feb 2018 13:03:50 -0800 Subject: Better jcov integration In-Reply-To: <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com> References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com> Message-ID: <5A971936.2070707@oracle.com> Alexey, Eric, Maurizio set a useful and relevant precedent when he contributed the IntelliJ plugin for jtreg. I think it is useful to keep separate the code for a tool (like jtreg or JCov) from any code that "wraps" the functionality of a tool into a plugin for some larger system, such as an IDE or CI system, but keeping it separate does not inherently mandate keeping it out of a Code Tools repository ... and having a "plugins" directory in a repo could well be a good way to go. It also helps keep separate any maintenance concerns of the primary functionality of the tool or library from any wrapper code that is specific to an external system, but facilitates combined building and testing where practical. -- Jon On 02/28/2018 12:20 PM, Alexey Fedorchenko wrote: > Hello, Eric! > > Thank you for the report. I have added an issue for your request [1]. > We will address it, I also think that having more report formats is a > good suggestion. > > A few thoughts about the original problem of adding JCov to CI (Jenkins): > - use html publisher plugin to show JCov html report > - plot build data with plot plugin to look at the coverage trend for > builds > ( it will require using grep and sed to get data from > overview-summary.html to plot.csv ) > - create JCov plugin for Jenkins. > > The latest item and Maven plugin opens a little bit bigger discussion > for Code Tools projects: > Could we have tool's plugins sources in tool?s repository? > > Thank you. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902125 > > ?Alexey > >> On Feb 28, 2018, at 4:42 AM, Eric McCorkle > > wrote: >> >> Hello everyone, >> >> I recently found myself needing better integration of jcov into various >> build/testing tools, so I did two things. First, I modified the jcov >> tool to generate a report in the Cobertura XML format, which is used by >> Jenkins and other tools as an input format. While these reports are >> inferior in my opinion to the HTML reports jcov generates, they do allow >> integration with other tools and CI systems. Therefore, I think >> providing this functionality would likely encourage more people to use >> jcov over the alternatives. >> >> I've attached the patch for this modification here, if anyone would like >> to review it. >> >> >> I've also mostly wrangled the Maven plugin API to create a plugin for >> using jcov in a Maven project (however, there is one remaining issue >> with documentation generation that I need to correct before I call the >> plugin "finished"). I'm not sure if that would be something that would >> be added to codetools, if the group ID should be something like >> "org.openjdk", or what else ought to be done about it. I will gladly >> contribute the code if there's a desire to adopt it. >> > From kevin.looney at oracle.com Wed Feb 28 21:12:19 2018 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 28 Feb 2018 13:12:19 -0800 Subject: Better jcov integration In-Reply-To: <5A971936.2070707@oracle.com> References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net> <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com> <5A971936.2070707@oracle.com> Message-ID: <645767c7-9ced-0b52-acbb-e9d6fc01d005@oracle.com> Seconded! Alexey and I had a very similar discussion this morning, and came up with some pseudo-priorities: 1.) Follow any Oracle mandates regarding external dependencies 2.) Limit-liability within a (little-p) project by keeping plugin/external-dependency related code separate/branched from the core of the project. It might be nice to have a convention across all code-tools, like a "plugins directory".?? I'm not sure if 'plugins' is the right name, but that certainly is one category of external dependencies. In any case, I'm not sure which way to go for us on support for Maven (we are already inconsistent in support, since we provided something for SigTest - on Bill Shannon's request).? Still leaning towards Oracle's mandate against (not sure I wish to fight with Legal over that). Thanks, Kevin On 2/28/18 1:03 PM, Jonathan Gibbons wrote: > Alexey, Eric, > > Maurizio set a useful and relevant precedent when he contributed the > IntelliJ plugin for jtreg. > > I think it is useful to keep separate the code for a tool (like jtreg > or JCov) from any code > that "wraps" the functionality of a tool into a plugin for some larger > system, such as an > IDE or CI system, but keeping it separate does not inherently mandate > keeping it out of > a? Code Tools repository ... and having a "plugins" directory in a > repo could well be a > good way to go. It also helps keep separate any maintenance concerns > of the primary > functionality of the tool or library from any wrapper code that is > specific to an external > system, but facilitates combined building and testing where practical. > > -- Jon > > > On 02/28/2018 12:20 PM, Alexey Fedorchenko wrote: >> Hello, Eric! >> >> Thank you for the report. I have added an issue for your request [1]. >> We will address it, I also think that having more report formats is a >> good suggestion. >> >> A few thoughts about the original problem of adding JCov to CI >> (Jenkins): >> - use html publisher plugin to show JCov html report >> - plot build data with plot plugin to look at the coverage trend for >> builds >> ( it will require using grep and sed to get data from >> overview-summary.html to plot.csv ) >> - create JCov plugin for Jenkins. >> >> The latest item and Maven plugin opens a little bit bigger discussion >> for Code Tools projects: >> Could we have tool's plugins sources in tool?s repository? >> >> Thank you. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902125 >> >> ?Alexey >> >>> On Feb 28, 2018, at 4:42 AM, Eric McCorkle >> > wrote: >>> >>> Hello everyone, >>> >>> I recently found myself needing better integration of jcov into various >>> build/testing tools, so I did two things.? First, I modified the jcov >>> tool to generate a report in the Cobertura XML format, which is used by >>> Jenkins and other tools as an input format.? While these reports are >>> inferior in my opinion to the HTML reports jcov generates, they do >>> allow >>> integration with other tools and CI systems.? Therefore, I think >>> providing this functionality would likely encourage more people to use >>> jcov over the alternatives. >>> >>> I've attached the patch for this modification here, if anyone would >>> like >>> to review it. >>> >>> >>> I've also mostly wrangled the Maven plugin API to create a plugin for >>> using jcov in a Maven project (however, there is one remaining issue >>> with documentation generation that I need to correct before I call the >>> plugin "finished").? I'm not sure if that would be something that would >>> be added to codetools, if the group ID should be something like >>> "org.openjdk", or what else ought to be done about it.? I will gladly >>> contribute the code if there's a desire to adopt it. >>> >> > -- kevin.looney at oracle.com