From smarlow at redhat.com Thu Dec 3 16:03:19 2020 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 3 Dec 2020 11:03:19 -0500 Subject: Newbie help needed getting setup to build SigTest + discussion about adding a exclude class by name option ... Message-ID: <812e16b0-af70-52a5-c8ab-b6440b97992c@redhat.com> Hi, I'm following the [1] guide to build locally but still have a few questions. Is there a particular version of Apache Ant needed to build? I downloaded 1.9.15 as that should work with Java 7 but am getting a build failure [2]: ` src/com/sun/tdk/signaturetest/ant/ATest.java:165: error: cannot find symbol [javac] if (classpath == null || classpath.isEmpty()) { ` I would like to explore a few ideas with SigTest related to [3] for the Jakarta EE Platform TCK which heavily depends on SigTest for SPEC API signature testing. Basically, we have users that would like to run our TCK against newer versions of Java SE than we have tested against. These users like the idea of being able to run the TCKs against the very latest Java SE versions. Since our (Jakarta EE Platform TCK) is basically a Java application, it would be very useful to be able to run our Jakarta EE Platform EE TCKs against any Java SE version that is greater than our base requirement (currently we only support Java SE 8 but are working on Java SE 11 now). One idea is to create a SigTest pull request for adding an exclude class option so that the java.lang.Object public methods/fields will be excluded from signature generation/testing. Imo, this should be a general option that allows a set of classes to be excluded (perhaps with some regular expression matching) and also allowing the command line exclude option to be specified multiple times (for excluding multiple classes by name). At least that is one idea. My preference is to do this work upstream first [4]. If there is no interest in the pull request being merged, the next option could be forking the SigTest code into the jakartaee-tck-tools [5] and making the change there. Either option would be easy figure out once we have appropriate changes. One other possible issue or question is whether this exclude class option would be a safe option to add to the OpenJDK SigTest tool? More specifically, could OpenJDK implementors use such an exclude option to cheat the JDK signature tests? I'm not sure how that would happen but if that is a concern, please do speak up about that, so we can just proceed to do fork of SigTest. From a timing perspective, this `exclude class` change is not required at this point in our planning but it would be very very nice to have! Scott [1] https://wiki.openjdk.java.net/display/CodeTools/How+to+build [2] https://gist.github.com/scottmarlow/b48890c8c5365264a4e7ea5c44c0778c [3] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156 [4] http://hg.openjdk.java.net/code-tools/sigtest [5] https://github.com/eclipse-ee4j/jakartaee-tck-tools From victor.rudometov at oracle.com Sat Dec 5 08:18:13 2020 From: victor.rudometov at oracle.com (victor.rudometov at oracle.com) Date: Sat, 5 Dec 2020 00:18:13 -0800 Subject: Newbie help needed getting setup to build SigTest + discussion about adding a exclude class by name option ... In-Reply-To: <812e16b0-af70-52a5-c8ab-b6440b97992c@redhat.com> References: <812e16b0-af70-52a5-c8ab-b6440b97992c@redhat.com> Message-ID: <0982f738-d912-6ed2-1c1b-305c300adccf@oracle.com> Hi Scott, Thank you for your interest in SigTest. Please find my answers below. On 12/3/20 08:03, Scott Marlow wrote: > Hi, > > I'm following the [1] guide to build locally but still have a few > questions.? Is there a particular version of Apache Ant needed to > build? ?I downloaded 1.9.15 as that should work with Java 7 but am > getting a build failure [2]: > ` > src/com/sun/tdk/signaturetest/ant/ATest.java:165: error: cannot find > symbol > ??? [javac]???????? if (classpath == null || classpath.isEmpty()) { [1] is outdated and needs to be refreshed. I'm using ant 1.10.8 (older ones should work as well) with the following minimal parameters: ant -f build/build.xml -Djdk7.home=/ws/java/java8 -Djdk8.home=/ws/java/java8 -Djdk9.home=/ws/java/java11 Please use Java 8 for jdk7.home. There's probably a way to still use 7, I have not checked it. You can use Java 9 or higher for jdk9.home, but I would recommend Java 11 or higher, since 11 is LTS. You can use 15 or 16 too as jdk8.home and jdk9.home if features like records or sealed types are present in your implementation. Sigtest supports them. > I would like to explore a few ideas with SigTest related to [3] for > the Jakarta EE Platform TCK which heavily depends on SigTest for SPEC > API signature testing.? Basically, we have users that would like to > run our TCK against newer versions of Java SE than we have tested > against. These users like the idea of being able to run the TCKs > against the very latest Java SE versions.? Since our (Jakarta EE > Platform TCK) is basically a Java application, it would be very useful > to be able to run our Jakarta EE Platform EE TCKs against any Java SE > version that is greater than our base requirement (currently we only > support Java SE 8 but are working on Java SE 11 now). > > One idea is to create a SigTest pull request for adding an exclude > class option so that the java.lang.Object public methods/fields will > be excluded from signature generation/testing. I guess the functionality that you need is already there. You can specify what should be tested by using -Package and -PackageWithoutSubpackages options. You can also filter out packages (with subpackages) or individual classes using -Exclude option. If that is not flexible enough there is a possibility to create an exclude plugin and set it via system property "exclude.plugin". Take a look at com.sun.tdk.exclude.ExcludeList and -ExcludeSig option allowing signature exclusions using regexps. > Imo, this should be a general option that allows a set of classes to > be excluded (perhaps with some regular expression matching) and also > allowing the command line exclude option to be specified multiple > times (for excluding multiple classes by name). > > At least that is one idea.? My preference is to do this work upstream > first [4].? If there is no interest in the pull request being merged, > the next option could be forking the SigTest code into the > jakartaee-tck-tools [5] and making the change there. Either option > would be easy figure out once we have appropriate changes. Contributions are very much welcome. This mailing list is the best place to discuss new needed things in SigTest. Thanks. Victor. > One other possible issue or question is whether this exclude class > option would be a safe option to add to the OpenJDK SigTest tool? More > specifically, could OpenJDK implementors use such an exclude option to > cheat the JDK signature tests?? I'm not sure how that would happen but > if that is a concern, please do speak up about that, so we can just > proceed to do fork of SigTest. > > From a timing perspective, this `exclude class` change is not required > at this point in our planning but it would be very very nice to have! > > Scott > > [1] https://wiki.openjdk.java.net/display/CodeTools/How+to+build > [2] https://gist.github.com/scottmarlow/b48890c8c5365264a4e7ea5c44c0778c > [3] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156 > [4] http://hg.openjdk.java.net/code-tools/sigtest > [5] https://github.com/eclipse-ee4j/jakartaee-tck-tools > From ehelin at openjdk.java.net Wed Dec 9 10:37:43 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Wed, 9 Dec 2020 10:37:43 GMT Subject: RFR: Update .jcheck/conf Message-ID: Hi all, please review this patch that updates the `.jcheck/conf` file to the format supported by Skara. Thanks, Erik ------------- Commit messages: - Update .jcheck/conf Changes: https://git.openjdk.java.net/sigtest/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=sigtest&pr=1&range=00 Stats: 43 lines in 1 file changed: 40 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/sigtest/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/sigtest pull/1/head:pull/1 PR: https://git.openjdk.java.net/sigtest/pull/1 From vrudomet at openjdk.java.net Wed Dec 9 20:24:37 2020 From: vrudomet at openjdk.java.net (Victor Rudometov) Date: Wed, 9 Dec 2020 20:24:37 GMT Subject: RFR: Update .jcheck/conf In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 10:34:14 GMT, Erik Helin wrote: > Hi all, > > please review this patch that updates the `.jcheck/conf` file to the format supported by Skara. > > Thanks, > Erik Marked as reviewed by vrudomet (Committer). ------------- PR: https://git.openjdk.java.net/sigtest/pull/1 From duke at openjdk.java.net Thu Dec 10 09:02:14 2020 From: duke at openjdk.java.net (duke) Date: Thu, 10 Dec 2020 09:02:14 GMT Subject: git: openjdk/sigtest: Update .jcheck/conf Message-ID: <34d6e399-7273-4843-96a1-96bc10980103@openjdk.java.net> Changeset: 282de13a Author: Erik Duveblad Committer: GitHub Date: 2020-12-10 10:01:51 +0000 URL: https://git.openjdk.java.net/sigtest/commit/282de13a Update .jcheck/conf ! .jcheck/conf From ehelin at openjdk.java.net Thu Dec 10 09:04:37 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Thu, 10 Dec 2020 09:04:37 GMT Subject: Withdrawn: Update .jcheck/conf In-Reply-To: References: Message-ID: <2elPnkhCq8Qzm21UZdJlaRXZZSlI5twxkEdGARg_1mU=.c45ab4c7-f52b-4b3c-b28d-1dd6c04f2f29@github.com> On Wed, 9 Dec 2020 10:34:14 GMT, Erik Helin wrote: > Hi all, > > please review this patch that updates the `.jcheck/conf` file to the format supported by Skara. > > Thanks, > Erik This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/sigtest/pull/1