From magnus.ihse.bursie at oracle.com Tue Feb 11 23:36:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Feb 2014 08:36:45 +0100 Subject: RFR webrev: 7900311 webrev -r doesn't produce an exported changeset file In-Reply-To: <52FAD5AC.6070309@oracle.com> References: <52B62279.5090603@oracle.com> <52E9AF26.7030309@oracle.com> <164F49E5-08C9-4EB0-9361-B7AAF882AFF6@oracle.com> <52EAC3E4.4020707@oracle.com> <52FAD5AC.6070309@oracle.com> Message-ID: <52FB248D.1060704@oracle.com> On 2014-02-12 03:00, Stuart Marks wrote: > Hi, is there someone who can push this changeset for me? Sorry, I can't help you. :-( I don't have committer rights to webrev, since code-tools committer rights is required for that, which I don't have. I'm cross-posting to code-tools-dev to see if someone there can step up. /Magnus > > Thanks. > > s'marks > > On 1/30/14 1:28 PM, Stuart Marks wrote: >> I've updated the version number and the copyright year as well. The >> patch has >> now tripled in size. :-) >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.1/ >> >> s'marks >> >> On 1/30/14 1:03 PM, Mike Duigou wrote: >>> >>> On Jan 29 2014, at 17:47 , Stuart Marks >>> wrote: >>> >>>> I was frustrated today because webrev was producing a plain patch file >>>> instead of an exported changeset file. Then I realized I had run >>>> across this >>>> before. See message appended below. (Probably dropped because of >>>> the holidays.) >>>> >>>> I've filed >>>> >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7900311 >>>> >>>> for this. I've also run my modified webrev.ksh over this patch to >>>> webrev.ksh >>>> and have uploaded a webrev here: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.0/ >>>> >>>> It's basically the same one-line change shown below. I don't think >>>> I have >>>> commit rights to the webrev repo; can someone push this for me? >>> >>> Please bump the version number. >>> >>>> >>>> Two observations, independent of this change: >>>> >>>> a) Even though this is a one-line change, the sdiff and frames >>>> views show a >>>> lot of spurious segments of the file, with no apparent changes. >>> >>> Quite odd. The udiff is in contrast nicely compact as is the actual >>> changeset. >>> >>>> >>>> b) The link in the changeset comment points to JDK-7900311, which >>>> doesn't >>>> exist, since the bug is actually CODETOOLS-7900311. >>> >>> The -c option needs to be extended to understand full bug ids. >>> >>>> >>>> Thanks, >>>> >>>> s'marks >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: bug in webrev? export vs patch >>>> Date: Sat, 21 Dec 2013 15:21:29 -0800 >>>> From: Stuart Marks >>>> To: webrev-dev at openjdk.java.net >>>> CC: Mike Duigou >>>> >>>> Hi all, >>>> >>>> My typical workflow is to keep the changes I'm working on in MQ, >>>> and then >>>> generate a webrev based on the tipmost applied patch. Typically >>>> this is the only >>>> applied patch, so I use a command like >>>> >>>> webrev -N -r qparent >>>> >>>> to generate a webrev from this patch. Unfortunately, in this mode, >>>> webrev >>>> doesn't export the hg changeset, instead it just generates a patch. >>>> There's an >>>> actual changeset present, so it should export it, so I think that's >>>> a bug. >>>> >>>> (I guess I should file a CODETOOLS bug on this.) >>>> >>>> What to do about this? Well, I think there's a case in handling the >>>> -r flag >>>> where a bit more of the global state needs to be set. It correctly >>>> picks up the >>>> changeset comment but doesn't set the flag that eventually causes >>>> the changeset >>>> to be exported instead of a patch to be generated. >>>> >>>> I've tried this: >>>> >>>> >>>> diff -r 9eab6a0ae4b5 webrev.ksh >>>> --- a/webrev.ksh Fri Nov 08 09:36:55 2013 +0100 >>>> +++ b/webrev.ksh Sat Dec 21 15:11:40 2013 -0800 >>>> @@ -2008,6 +2008,7 @@ >>>> # >>>> FIRST_CREV=`hg log --rev $PARENT_REV --template '{rev}'` >>>> FIRST_CREV=`expr $FIRST_CREV + 1` >>>> + HG_LIST_FROM_COMMIT=1 >>>> fi >>>> fi >>>> #Let's check if a merge is needed, if so, issue a warning >>>> >>>> >>>> I haven't analyzed all the ways the various global variables are >>>> used though. >>>> However, using this patch "works for me" .... >>>> >>>> s'marks >>>> >>>> >>> From kevin.looney at oracle.com Wed Feb 26 13:31:12 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 26 Feb 2014 13:31:12 -0800 Subject: CodeTools proposal: "JTHarness" Message-ID: <530E5D20.3060200@oracle.com> Name: JTHarness Summary: A collection of tools used to evaluate platform compatibility and API change. Proposed by: Kevin Looney Rationale: JTHarness is already an Open Source project, located under the ME OpenSource infrastructure: https://jtharness.java.net/ This is not a proposal for a new project, it is a proposal for a transfer of the JTHarness (java.net) project into the OpenJDK CodeTools community, and moderation under OpenJDK bylaws. The JT harness is based on Oracle's JavaTest (TM) Harness. The JT harness is a general purpose, fully-featured, flexible, and configurable test harness very well suited for most types of unit testing. Originally developed as a test harness to run Technology Compatibility Kit (TCK) test suites, it has since evolved into a general purpose test platform. The JT harness: * Is designed to configure, sequence, and run test suites that consist of many (100,000 or more) discrete, independent tests. It is especially good at testing APIs and compilers. * Can be used to run tests on all of the Java platforms, from the Java Card platform, to the Java Platform, Enterprise Edition ("Java EE"). * Enables you to create test suites that are self-contained products that customers can easily configure and run. The JTHarness open source project was created in 2006 - in order to develop a community that will improve the harness, improve software development techniques with respect to platform compatibility, and enhance the development of software test suites. We expect to continue this charter through inclusion in OpenJDK. -- kevin.looney at oracle.com From kevin.looney at oracle.com Wed Feb 26 13:31:19 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 26 Feb 2014 13:31:19 -0800 Subject: CodeTools proposal: "SigTest" Message-ID: <530E5D27.8020008@oracle.com> Name: SigTest Summary: A collection of tools used to evaluate platform compatibility and API change. Proposed by: Kevin Looney Rationale: SigTest is already an Open Source project, located under the ME OpenSource infrastructure: https://sigtest.java.net/ This is not a proposal for a new project, it is a proposal for a transfer of the SigTest (java.net) project into the OpenJDK CodeTools community, and moderation under OpenJDK bylaws. The SigTest open source project is a collection of tools, originally based on Oracle's commercial SigTest tools product. The SigTest tools can be used to compare APIs and to measure the test coverage of an API. The tools were originally created to assist in the creation of Java technology compatibility test suites (TCKs), but are also useful in the creation of other types of test suites and in the software development process. The SigTest project consists of the following tools. The *Signature Test tool* - makes it easy to compare the signatures of two different implementations or different versions of the same API. When it compares different implementations of the same API, the tool verifies that all of the members are present, reports when new members are added, and checks the specified behavior of each API member. When it compares different versions of the same API, the tool checks that the old version can be replaced by the new one without adversely affecting existing clients of the API. The *API Coverage tool* can be used to estimate the test coverage a test suite provides for an implementation of a specified API. It does this by determining how many public class members the test suite references within the API specification. The tool uses a signature file representation of the API specification as the source of specification analysis. It does not process a formal specification in any form. The *API Check tool* tracks API changes and roughly checks for source and binary compatibility. Much like Signature Test tool, it compares the reference implementation of an API recorded as golden signature file with a tested implementation. Unlike Signature Test tool, which requires that all classes (and the classes they depend on) be specified to the tool, API Check tool does not require dependencies to be specified. For that reason, API Check tool is faster than Signature Test tool, but less rigorous. The SigTest open source project was created in 2008 - in order to develop a community that will improve the tools, improve software development techniques with respect to platform compatibility, and enhance the development of software test suites. We expect to continue this charter through inclusion in OpenJDK. -- kevin.looney at oracle.com From kevin.looney at oracle.com Wed Feb 26 13:39:32 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 26 Feb 2014 13:39:32 -0800 Subject: CodeTools proposal: "JTHarness" In-Reply-To: <530E5D20.3060200@oracle.com> References: <530E5D20.3060200@oracle.com> Message-ID: <530E5F14.20906@oracle.com> Sorry - the summary should read: Summary: A software testing harness, used to to drive large-scale Java platform testing. On 2/26/14, 1:31 PM, Kevin Looney wrote: > Name: JTHarness > > Summary: A collection of tools used to evaluate platform compatibility > and API change. > > Proposed by: Kevin Looney > > Rationale: > > JTHarness is already an Open Source project, located under the ME > OpenSource infrastructure: > > https://jtharness.java.net/ > > This is not a proposal for a new project, it is a proposal for a > transfer of the JTHarness (java.net) project into the OpenJDK > CodeTools community, and moderation under OpenJDK bylaws. > > The JT harness is based on Oracle's JavaTest (TM) Harness. The JT > harness is a general purpose, fully-featured, flexible, and > configurable test harness very well suited for most types of unit > testing. Originally developed as a test harness to run Technology > Compatibility Kit (TCK) test suites, it has since evolved into a > general purpose test platform. > > The JT harness: > > * Is designed to configure, sequence, and run test suites that consist > of many (100,000 or more) discrete, independent tests. It is > especially good at testing APIs and compilers. > * Can be used to run tests on all of the Java platforms, from the Java > Card platform, to the Java Platform, Enterprise Edition ("Java EE"). > * Enables you to create test suites that are self-contained products > that customers can easily configure and run. > > The JTHarness open source project was created in 2006 - in order to > develop a community that will improve the harness, improve software > development techniques with respect to platform compatibility, and > enhance the development of software test suites. We expect to continue > this charter through inclusion in OpenJDK. > -- kevin.looney at oracle.com From kevin.looney at oracle.com Wed Feb 26 14:21:54 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 26 Feb 2014 14:21:54 -0800 Subject: CodeTools proposal: "JCov" Message-ID: <530E6902.3080403@oracle.com> 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. -- kevin.looney at oracle.com From jonathan.gibbons at oracle.com Wed Feb 26 14:36:47 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Feb 2014 14:36:47 -0800 Subject: CodeTools proposal: "JCov" In-Reply-To: <530E6902.3080403@oracle.com> References: <530E6902.3080403@oracle.com> Message-ID: <530E6C7F.80703@oracle.com> 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. >