From alexandre.iline at oracle.com Thu May 3 22:20:54 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 3 May 2018 15:20:54 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. Message-ID: Hi. Could you please take a look on this suggested addition to JCov. It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 Thank you. Shura From alexey.fedorchenko at oracle.com Tue May 8 18:54:17 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Tue, 8 May 2018 11:54:17 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: References: Message-ID: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> Hello! Thank you for the contribution. Could you, please, address these few things to look deeper in the plugin functionality: - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. - default target in the build.xml is ?dist? but the target does not exist in the build.xml - what ASM is required by the plugin? Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). Thank you. ?Alexey > On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: > > Hi. > > Could you please take a look on this suggested addition to JCov. > > It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. > > Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. > > Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. > > Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. > > Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 > > Thank you. > > Shura > From alexandre.iline at oracle.com Tue May 8 21:03:53 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 8 May 2018 14:03:53 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> Message-ID: <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> > On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: > > Hello! > > Thank you for the contribution. > > Could you, please, address these few things to look deeper in the plugin functionality: > - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. > - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. > - default target in the build.xml is ?dist? but the target does not exist in the build.xml Oh!. Oversight - thanks! > - what ASM is required by the plugin? > Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). Let me look into that. Thanks! Shura > > Thank you. > > > ?Alexey > > >> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Could you please take a look on this suggested addition to JCov. >> >> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >> >> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >> >> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >> >> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >> >> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >> >> Thank you. >> >> Shura >> > From alexandre.iline at oracle.com Wed May 9 00:24:14 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 8 May 2018 17:24:14 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> Message-ID: New version: http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ Shura > On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: > > > >> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >> >> Hello! >> >> Thank you for the contribution. >> >> Could you, please, address these few things to look deeper in the plugin functionality: >> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) > > Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. > >> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. > > You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. > > ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. > > >> - default target in the build.xml is ?dist? but the target does not exist in the build.xml > > Oh!. Oversight - thanks! > >> - what ASM is required by the plugin? > >> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). > > Let me look into that. > > Thanks! > > Shura > > >> >> Thank you. >> >> >> ?Alexey >> >> >>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>> >>> Hi. >>> >>> Could you please take a look on this suggested addition to JCov. >>> >>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>> >>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>> >>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>> >>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>> >>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>> >>> Thank you. >>> >>> Shura >>> >> > From alexey.fedorchenko at oracle.com Thu May 10 00:24:56 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Wed, 9 May 2018 17:24:56 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> Message-ID: <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> Thanks for the update! The tests? approach (to verify the test class itself) looks nice to me. A few things: - please, add the author to the readme file. - usage string has two names for the plugin?s jar (readme and Scanner.java): "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + "\n" + "java -classpath jcov.jar:simple_methods_anc.jar ? (btw do we need 2 lines here? The first command will not succeed.) - include/exclude options (long and short names) differs in readme and in command line. - if no filters are specified the output differs from the command line options: One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) and lastDot variable in the visitClass method (Scanner.java) - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). - command without uri schema will give NullPointerException (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. Thank you. ?Alexey > On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: > > New version: > http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ > > Shura > >> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline > wrote: >> >> >> >>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko > wrote: >>> >>> Hello! >>> >>> Thank you for the contribution. >>> >>> Could you, please, address these few things to look deeper in the plugin functionality: >>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >> >> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >> >>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >> >> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >> >> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >> >> >>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >> >> Oh!. Oversight - thanks! >> >>> - what ASM is required by the plugin? >> >>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >> >> Let me look into that. >> >> Thanks! >> >> Shura >> >> >>> >>> Thank you. >>> >>> >>> ?Alexey >>> >>> >>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline > wrote: >>>> >>>> Hi. >>>> >>>> Could you please take a look on this suggested addition to JCov. >>>> >>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>> >>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>> >>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>> >>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>> >>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>> >>>> Thank you. >>>> >>>> Shura >>>> >>> >> > From alexandre.iline at oracle.com Thu May 10 02:40:14 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 9 May 2018 19:40:14 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> Message-ID: Thank you very much for the discovered inconsistencies and problems. With the exception of one, all fixed. > On May 9, 2018, at 5:24 PM, Alexey Fedorchenko wrote: > > Thanks for the update! > The tests? approach (to verify the test class itself) looks nice to me. > > A few things: > > - please, add the author to the readme file. Done > > - usage string has two names for the plugin?s jar (readme and Scanner.java): > "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + > "\n" + > "java -classpath jcov.jar:simple_methods_anc.jar ? Fixed. > (btw do we need 2 lines here? The first command will not succeed.) Not sure what you mean. Does passing ?usage fail? > > - include/exclude options (long and short names) differs in readme and in command line. Fixed. > > - if no filters are specified the output differs from the command line options: > One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified Fixed. > > - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) > and lastDot variable in the visitClass method (Scanner.java) Leftover from an old algorithm. Removed. > > - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). Fixed. > > - command without uri schema will give NullPointerException > (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) Throwing a RuntimeException now. > > - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. > It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: > "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? Shura > > > Thank you. > > ?Alexey > > >> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >> >> New version: >> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >> >> Shura >> >>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: >>> >>> >>> >>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >>>> >>>> Hello! >>>> >>>> Thank you for the contribution. >>>> >>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>> >>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>> >>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>> >>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>> >>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>> >>> >>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>> >>> Oh!. Oversight - thanks! >>> >>>> - what ASM is required by the plugin? >>> >>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>> >>> Let me look into that. >>> >>> Thanks! >>> >>> Shura >>> >>> >>>> >>>> Thank you. >>>> >>>> >>>> ?Alexey >>>> >>>> >>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> Hi. >>>>> >>>>> Could you please take a look on this suggested addition to JCov. >>>>> >>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>> >>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>> >>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>> >>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>> >>>>> Thank you. >>>>> >>>>> Shura >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Thu May 10 02:52:52 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 9 May 2018 19:52:52 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> Message-ID: On 5/9/18 5:24 PM, Alexey Fedorchenko wrote: > Thanks for the update! > The tests? approach (to verify the test class itself) looks nice to me. > > A few things: > > - please, add the author to the readme file. Although opinions differ, author info in files is generally discouraged. Authorship is generally more accurately tracked through the SCM history. > > - usage string has two names for the plugin?s jar (readme and Scanner.java): > "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + > "\n" + > "java -classpath jcov.jar:simple_methods_anc.jar ? > (btw do we need 2 lines here? The first command will not succeed.) > > - include/exclude options (long and short names) differs in readme and in command line. > > - if no filters are specified the output differs from the command line options: > One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified > > - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) > and lastDot variable in the visitClass method (Scanner.java) > > - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). > > - command without uri schema will give NullPointerException > (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) > > - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. > It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: > "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. Please consider following the guidelines in JEP 293, unless there is a compelling reason to do otherwise. http://openjdk.java.net/jeps/293 Options should either be "long-form" ... a short series of words prefixed by '--' and separated by '-',? or "short-form", a '-' followed by a single letter. Arguments may follow the name of a option separated by '=' or whitespace. ??? --this-is-an-option ??? -t ??? --this-option-has-a-value=3 ??? --this-option-has-a-value=3 ??? -u 3 > > > Thank you. > > ?Alexey > > >> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >> >> New version: >> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >> >> Shura >> >>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline > wrote: >>> >>> >>> >>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko > wrote: >>>> >>>> Hello! >>>> >>>> Thank you for the contribution. >>>> >>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>> >>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>> >>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>> >>> >>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>> Oh!. Oversight - thanks! >>> >>>> - what ASM is required by the plugin? >>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>> Let me look into that. >>> >>> Thanks! >>> >>> Shura >>> >>> >>>> Thank you. >>>> >>>> >>>> ?Alexey >>>> >>>> >>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline > wrote: >>>>> >>>>> Hi. >>>>> >>>>> Could you please take a look on this suggested addition to JCov. >>>>> >>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>> >>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>> >>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>> >>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>> >>>>> Thank you. >>>>> >>>>> Shura >>>>> From alexey.fedorchenko at oracle.com Thu May 10 06:20:47 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Wed, 9 May 2018 23:20:47 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> Message-ID: <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> > Not sure what you mean. Does passing ?usage fail? I am reading the first line ?java -classpath jcov.jar:SimpleMethods.jar --usage ? as an input command (maybe I should not). But if it is a command to run - the result will not be the usage of the plugin (user needs to specify openjdk.jcov.filter.simplemethods.Scanner class). > Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? No. You can use these methods. The problem is that you combine packages' filters and modules' filters together in one array, for an example you can have in includes both ?java.base? and ?java.util? patterns now. If you keep modules separate from the packages and verify class name and module name against the patterns accordingly you will be able to receive expected results from Utils.accept invocations. ?Alexey > On May 9, 2018, at 7:40 PM, Alexandre (Shura) Iline wrote: > > Thank you very much for the discovered inconsistencies and problems. With the exception of one, all fixed. > >> On May 9, 2018, at 5:24 PM, Alexey Fedorchenko wrote: >> >> Thanks for the update! >> The tests? approach (to verify the test class itself) looks nice to me. >> >> A few things: >> >> - please, add the author to the readme file. > > Done > >> >> - usage string has two names for the plugin?s jar (readme and Scanner.java): >> "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + >> "\n" + >> "java -classpath jcov.jar:simple_methods_anc.jar ? > > Fixed. > >> (btw do we need 2 lines here? The first command will not succeed.) > > Not sure what you mean. Does passing ?usage fail? > >> >> - include/exclude options (long and short names) differs in readme and in command line. > > Fixed. > >> >> - if no filters are specified the output differs from the command line options: >> One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified > > Fixed. > >> >> - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) >> and lastDot variable in the visitClass method (Scanner.java) > > Leftover from an old algorithm. Removed. > >> >> - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). > > Fixed. > >> >> - command without uri schema will give NullPointerException >> (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) > > Throwing a RuntimeException now. > >> >> - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. >> It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: >> "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. > > Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? > > > Shura > >> >> >> Thank you. >> >> ?Alexey >> >> >>> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >>> >>> New version: >>> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >>> >>> Shura >>> >>>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: >>>> >>>> >>>> >>>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >>>>> >>>>> Hello! >>>>> >>>>> Thank you for the contribution. >>>>> >>>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>>> >>>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>>> >>>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>>> >>>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>>> >>>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>>> >>>> >>>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>>> >>>> Oh!. Oversight - thanks! >>>> >>>>> - what ASM is required by the plugin? >>>> >>>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>>> >>>> Let me look into that. >>>> >>>> Thanks! >>>> >>>> Shura >>>> >>>> >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> ?Alexey >>>>> >>>>> >>>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> Hi. >>>>>> >>>>>> Could you please take a look on this suggested addition to JCov. >>>>>> >>>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>>> >>>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>>> >>>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>>> >>>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Shura >>>>>> >>>>> >>>> >>> >> > From alexandre.iline at oracle.com Thu May 10 16:21:20 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 10 May 2018 09:21:20 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> Message-ID: <2A34E7F9-B6E5-40E4-9C06-90AD094F1D4A@oracle.com> > On May 9, 2018, at 11:20 PM, Alexey Fedorchenko wrote: > >> Not sure what you mean. Does passing ?usage fail? > I am reading the first line ?java -classpath jcov.jar:SimpleMethods.jar --usage ? as an input command (maybe I should not). > But if it is a command to run - the result will not be the usage of the plugin (user needs to specify openjdk.jcov.filter.simplemethods.Scanner class). Ah! That?s why this line was originally written when I planned to use ?java -jar?. Sorry! > >> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? > No. You can use these methods. > The problem is that you combine packages' filters and modules' filters together in one array, for an example you can have in includes both ?java.base? and ?java.util? patterns now. > If you keep modules separate from the packages and verify class name and module name against the patterns accordingly you will be able to receive expected results from Utils.accept invocations. But how do I calculate the module name? I have just discovered that ClassNode.module is non-null only for module-info classes. Is this by design? Myself I can only calculate the module name for jrtfs, as there I know the path structure: /modules//. Still not too pretty but OK. I do not know presently how to do that for jar or exploded class hierarchy. Shura > > ?Alexey > > >> On May 9, 2018, at 7:40 PM, Alexandre (Shura) Iline wrote: >> >> Thank you very much for the discovered inconsistencies and problems. With the exception of one, all fixed. >> >>> On May 9, 2018, at 5:24 PM, Alexey Fedorchenko wrote: >>> >>> Thanks for the update! >>> The tests? approach (to verify the test class itself) looks nice to me. >>> >>> A few things: >>> >>> - please, add the author to the readme file. >> >> Done >> >>> >>> - usage string has two names for the plugin?s jar (readme and Scanner.java): >>> "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + >>> "\n" + >>> "java -classpath jcov.jar:simple_methods_anc.jar ? >> >> Fixed. >> >>> (btw do we need 2 lines here? The first command will not succeed.) >> >> Not sure what you mean. Does passing ?usage fail? >> >>> >>> - include/exclude options (long and short names) differs in readme and in command line. >> >> Fixed. >> >>> >>> - if no filters are specified the output differs from the command line options: >>> One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified >> >> Fixed. >> >>> >>> - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) >>> and lastDot variable in the visitClass method (Scanner.java) >> >> Leftover from an old algorithm. Removed. >> >>> >>> - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). >> >> Fixed. >> >>> >>> - command without uri schema will give NullPointerException >>> (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) >> >> Throwing a RuntimeException now. >> >>> >>> - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. >>> It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: >>> "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. >> >> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? >> >> >> Shura >> >>> >>> >>> Thank you. >>> >>> ?Alexey >>> >>> >>>> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >>>> >>>> New version: >>>> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >>>> >>>> Shura >>>> >>>>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> >>>>> >>>>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >>>>>> >>>>>> Hello! >>>>>> >>>>>> Thank you for the contribution. >>>>>> >>>>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>>>> >>>>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>>>> >>>>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>>>> >>>>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>>>> >>>>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>>>> >>>>> >>>>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>>>> >>>>> Oh!. Oversight - thanks! >>>>> >>>>>> - what ASM is required by the plugin? >>>>> >>>>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>>>> >>>>> Let me look into that. >>>>> >>>>> Thanks! >>>>> >>>>> Shura >>>>> >>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> ?Alexey >>>>>> >>>>>> >>>>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Could you please take a look on this suggested addition to JCov. >>>>>>> >>>>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>>>> >>>>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>>>> >>>>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>>>> >>>>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Thu May 10 16:28:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 May 2018 09:28:59 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <2A34E7F9-B6E5-40E4-9C06-90AD094F1D4A@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> <2A34E7F9-B6E5-40E4-9C06-90AD094F1D4A@oracle.com> Message-ID: On 5/10/18 9:21 AM, Alexandre (Shura) Iline wrote: > Myself I can only calculate the module name for jrtfs, as there I know the path structure:/modules//. Still not too pretty but OK. I do not know presently how to do that for jar or exploded class hierarchy. If a jar is a module, then the module name may come from ??? a module declarion (module-info.class) ??? an Automatic-Module-Name attribute in MANIFEST.MF ??? an automatic module name derived from the name of the jar file An exploded class hierarchy is just // -- Jon From alexandre.iline at oracle.com Thu May 10 22:34:20 2018 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 10 May 2018 15:34:20 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> Message-ID: <130A0521-4680-45BB-9132-26C267161DD4@oracle.com> Alexey, Jon, I decided, for now, remove capability of selecting code by module names. There is more work in that then I thought. I will create an enhancements for that in JBS - right after pushing the code. Other than that, I have addressed all comments, thank you, Alexey for your thoroughness. I have also added a few tests. This is the last webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.02/ If nobody says anything in a few days, I will assume everybody is satisfied and push. Shura > On May 9, 2018, at 11:20 PM, Alexey Fedorchenko wrote: > >> Not sure what you mean. Does passing ?usage fail? > I am reading the first line ?java -classpath jcov.jar:SimpleMethods.jar --usage ? as an input command (maybe I should not). > But if it is a command to run - the result will not be the usage of the plugin (user needs to specify openjdk.jcov.filter.simplemethods.Scanner class). > >> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? > No. You can use these methods. > The problem is that you combine packages' filters and modules' filters together in one array, for an example you can have in includes both ?java.base? and ?java.util? patterns now. > If you keep modules separate from the packages and verify class name and module name against the patterns accordingly you will be able to receive expected results from Utils.accept invocations. > > ?Alexey > > >> On May 9, 2018, at 7:40 PM, Alexandre (Shura) Iline wrote: >> >> Thank you very much for the discovered inconsistencies and problems. With the exception of one, all fixed. >> >>> On May 9, 2018, at 5:24 PM, Alexey Fedorchenko wrote: >>> >>> Thanks for the update! >>> The tests? approach (to verify the test class itself) looks nice to me. >>> >>> A few things: >>> >>> - please, add the author to the readme file. >> >> Done >> >>> >>> - usage string has two names for the plugin?s jar (readme and Scanner.java): >>> "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + >>> "\n" + >>> "java -classpath jcov.jar:simple_methods_anc.jar ? >> >> Fixed. >> >>> (btw do we need 2 lines here? The first command will not succeed.) >> >> Not sure what you mean. Does passing ?usage fail? >> >>> >>> - include/exclude options (long and short names) differs in readme and in command line. >> >> Fixed. >> >>> >>> - if no filters are specified the output differs from the command line options: >>> One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified >> >> Fixed. >> >>> >>> - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) >>> and lastDot variable in the visitClass method (Scanner.java) >> >> Leftover from an old algorithm. Removed. >> >>> >>> - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). >> >> Fixed. >> >>> >>> - command without uri schema will give NullPointerException >>> (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) >> >> Throwing a RuntimeException now. >> >>> >>> - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. >>> It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: >>> "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. >> >> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? >> >> >> Shura >> >>> >>> >>> Thank you. >>> >>> ?Alexey >>> >>> >>>> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >>>> >>>> New version: >>>> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >>>> >>>> Shura >>>> >>>>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> >>>>> >>>>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >>>>>> >>>>>> Hello! >>>>>> >>>>>> Thank you for the contribution. >>>>>> >>>>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>>>> >>>>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>>>> >>>>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>>>> >>>>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>>>> >>>>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>>>> >>>>> >>>>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>>>> >>>>> Oh!. Oversight - thanks! >>>>> >>>>>> - what ASM is required by the plugin? >>>>> >>>>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>>>> >>>>> Let me look into that. >>>>> >>>>> Thanks! >>>>> >>>>> Shura >>>>> >>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> ?Alexey >>>>>> >>>>>> >>>>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Could you please take a look on this suggested addition to JCov. >>>>>>> >>>>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>>>> >>>>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>>>> >>>>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>>>> >>>>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Shura >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexey.fedorchenko at oracle.com Fri May 11 02:12:55 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Thu, 10 May 2018 19:12:55 -0700 Subject: RFR 7902161 : Discover simple getters, setters, throwers and delegators. In-Reply-To: <130A0521-4680-45BB-9132-26C267161DD4@oracle.com> References: <801942F7-6801-469D-87FC-42573B3908C1@oracle.com> <1BD7508C-5BC2-4371-BC61-334247A163A9@oracle.com> <3D1A6137-8FF5-460B-9AE0-CF92F4DE3120@oracle.com> <81A0C0D0-BA70-4412-A741-DB60A0C77DA5@oracle.com> <130A0521-4680-45BB-9132-26C267161DD4@oracle.com> Message-ID: <7CA92B19-3458-44AF-A8DB-8B991EB8A79F@oracle.com> I agree with your decision - it is more than enough for the initial plugin's push. You can make all functional enhancements with the separate pushes. Thanks for the contribution! ?Alexey > On May 10, 2018, at 3:34 PM, Alexandre (Shura) Iline wrote: > > Alexey, Jon, > > I decided, for now, remove capability of selecting code by module names. There is more work in that then I thought. I will create an enhancements for that in JBS - right after pushing the code. > > Other than that, I have addressed all comments, thank you, Alexey for your thoroughness. I have also added a few tests. > > This is the last webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.02/ > > If nobody says anything in a few days, I will assume everybody is satisfied and push. > > Shura > >> On May 9, 2018, at 11:20 PM, Alexey Fedorchenko wrote: >> >>> Not sure what you mean. Does passing ?usage fail? >> I am reading the first line ?java -classpath jcov.jar:SimpleMethods.jar --usage ? as an input command (maybe I should not). >> But if it is a command to run - the result will not be the usage of the plugin (user needs to specify openjdk.jcov.filter.simplemethods.Scanner class). >> >>> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? >> No. You can use these methods. >> The problem is that you combine packages' filters and modules' filters together in one array, for an example you can have in includes both ?java.base? and ?java.util? patterns now. >> If you keep modules separate from the packages and verify class name and module name against the patterns accordingly you will be able to receive expected results from Utils.accept invocations. >> >> ?Alexey >> >> >>> On May 9, 2018, at 7:40 PM, Alexandre (Shura) Iline wrote: >>> >>> Thank you very much for the discovered inconsistencies and problems. With the exception of one, all fixed. >>> >>>> On May 9, 2018, at 5:24 PM, Alexey Fedorchenko wrote: >>>> >>>> Thanks for the update! >>>> The tests? approach (to verify the test class itself) looks nice to me. >>>> >>>> A few things: >>>> >>>> - please, add the author to the readme file. >>> >>> Done >>> >>>> >>>> - usage string has two names for the plugin?s jar (readme and Scanner.java): >>>> "java -classpath jcov.jar:SimpleMethods.jar --usage\n" + >>>> "\n" + >>>> "java -classpath jcov.jar:simple_methods_anc.jar ? >>> >>> Fixed. >>> >>>> (btw do we need 2 lines here? The first command will not succeed.) >>> >>> Not sure what you mean. Does passing ?usage fail? >>> >>>> >>>> - include/exclude options (long and short names) differs in readme and in command line. >>> >>> Fixed. >>> >>>> >>>> - if no filters are specified the output differs from the command line options: >>>> One or more of --simple getter,--simple setter,--simple delegator,--simple thrower,--empty methods options must be specified >>> >>> Fixed. >>> >>>> >>>> - unused methods in Utils.java (just to pay you attention,may be it is static methods for future usage) >>>> and lastDot variable in the visitClass method (Scanner.java) >>> >>> Leftover from an old algorithm. Removed. >>> >>>> >>>> - testng.jar property is not enough to run tests, users will need to add jcommander to the classpath (?test? target is not executable). >>> >>> Fixed. >>> >>>> >>>> - command without uri schema will give NullPointerException >>>> (java -jar jcov.jar:SimpleMethods.jar Scanner ?getters g.test /classes -> switch on null in Scanner) >>> >>> Throwing a RuntimeException now. >>> >>>> >>>> - include/exclude options will not work for modules - Scanner.java combines -i and -im and verifies classname against the filter. >>>> It means that for -im java.base class will be checked the same way as for -i java.base. You can reproduce the problem by modifying test in the MainTest: >>>> "-i", "java.util" -> "-im", ?java.base? should give the same test?s result. >>> >>> Does it mean that I am incorrectly using JCov API? Could you point out where I use it incorrectly? I have assumed that Utils.Pattern, if created with the third parameter set to true, would filter based on module name. This is what I seemed to find in JCov code. Could you point me where I am incorrect? >>> >>> >>> Shura >>> >>>> >>>> >>>> Thank you. >>>> >>>> ?Alexey >>>> >>>> >>>>> On May 8, 2018, at 5:24 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> New version: >>>>> http://cr.openjdk.java.net/~shurailine/7902161/webrev.01/ >>>>> >>>>> Shura >>>>> >>>>>> On May 8, 2018, at 2:03 PM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On May 8, 2018, at 11:54 AM, Alexey Fedorchenko wrote: >>>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> Thank you for the contribution. >>>>>>> >>>>>>> Could you, please, address these few things to look deeper in the plugin functionality: >>>>>>> - readme file can help plugin users to understand how to run the plugin and what to expect (for an example what minimal JDK to use because it differs from the JCov required level) >>>>>> >>>>>> Absolutely! The reason I did not do it right away is because I thought there could be comments on the command line syntax or functionality. Since you seem to be OK with both, I will proceed cresting the readme. >>>>>> >>>>>>> - build.xml has ?dest? ?testng.jar? properties, it looks like the patch missed the default properties file. >>>>>> >>>>>> You meant ?dist?. Y, sorry, fixed. The directory was just created but not used. Leftovers of pervious version. >>>>>> >>>>>> ?testing.jar? I think I am processing correctly. You can build without worrying about testng existence, but if you wanna run test, you need to provide it. I will make sure to mention that in readme. >>>>>> >>>>>> >>>>>>> - default target in the build.xml is ?dist? but the target does not exist in the build.xml >>>>>> >>>>>> Oh!. Oversight - thanks! >>>>>> >>>>>>> - what ASM is required by the plugin? >>>>>> >>>>>>> Current requirement (asm.tree.checksum) is set to asm-tree-6.0 by the OS JCov build, but Scanner class uses clazz.methods list as the list of the MethodNodes (the change from the 6.1). >>>>>> >>>>>> Let me look into that. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Shura >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>>>> ?Alexey >>>>>>> >>>>>>> >>>>>>>> On May 3, 2018, at 3:20 PM, Alexandre (Shura) Iline wrote: >>>>>>>> >>>>>>>> Hi. >>>>>>>> >>>>>>>> Could you please take a look on this suggested addition to JCov. >>>>>>>> >>>>>>>> It is a tool which could be used to discover ?simple? methods in the code to later be used for filtering of coverage data, such as for ANC code. >>>>>>>> >>>>>>>> Functionality: While writing, I did make a number of design choices which may or may not be the most practical ones, so I would welcome any sort of feedback. >>>>>>>> >>>>>>>> Testing: There are _some_ tests - not a complete coverage, which would require testing many combinations of bytecode operations. All tests are true ?unit? tests with the exception of MainTest. Tests are executable from ant build script. >>>>>>>> >>>>>>>> Documentation: There is _some_ javadoc here and there and there is a usage information - altogether not enough to consider the tool to be completely documented. But ? it?s an open-source and the code is right next to the documentation ? and the tool is for people with dev background, so I think we can start with what t is there already and add more later. Do let me know if something is incorrect, unclear or confusing - I will have it fixed. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~shurailine/7902161/webrev.00 >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> Shura >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandre.iline at oracle.com Thu May 17 01:44:02 2018 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 17 May 2018 01:44:02 +0000 Subject: hg: code-tools/jcov: 2 new changesets Message-ID: <201805170144.w4H1i20T004179@aojmv0008.oracle.com> Changeset: 2e8d8c4675db Author: shurailine Date: 2018-05-16 11:41 -0700 URL: http://hg.openjdk.java.net/code-tools/jcov/rev/2e8d8c4675db 7902161 : Discover simple getters, setters, throwers and delegators Reviewed-by: afedorch + plugins/simple_methods_anc/README.md + plugins/simple_methods_anc/build.xml + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Delegators.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/EmptyMethods.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Getters.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Scanner.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Setters.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Throwers.java + plugins/simple_methods_anc/src/openjdk/jcov/filter/simplemethods/Utils.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/DelegatorsTest.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/EmptyMethodsTest.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/GettersTest.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/MainTest.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/SettersTest.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/TestUtils.java + plugins/simple_methods_anc/test/openjdk/jcov/filter/simplemethods/ThrowersTest.java Changeset: c92eeb0e0400 Author: shurailine Date: 2018-05-16 11:43 -0700 URL: http://hg.openjdk.java.net/code-tools/jcov/rev/c92eeb0e0400 Merge