Newbie help needed getting setup to build SigTest + discussion about adding a exclude class by name option ...

[Scott Marlow]

On 1/7/21 5:23 PM, victor.rudometov at oracle.com wrote:
> Hi Scott,
>
> Technically the signatures do change when we switch from 8 to 11 and 
> annotations are either added to finalize() method or default empty 
> parameters are added to Deprecated. Annotation changes can affect the 
> behavior of reflective APIs that work with annotations, therefore 
> Sigtest is correct to report an error.
>
> If we do not want to track these I see exclude plugin as one of 
> possible options (through check() method there). Another one is to 
> work through PluginAPI and either transform or filter the signature.

Thanks, I will try the exclude plugin check() method.

Also, below is a list of what I am trying to accomplish (pending more 
discussion + feedback):

1.  Do verify that the super class name doesn't change but do not verify 
the super class contents (e.g. no JDK class content checking).
2.  Do verify that each annotation name is as expected but do not verify 
the actual annotation signature.
3.  Do verify each public class method/field signature.
4.  Do fail if any public class method/field are added (for no 
super-setting rule).
5.  Do fail if any public class method/field are removed (for no 
sub-setting rule).
6.  To be clear, any JDK class referenced by name in the Jakarta EE SPEC 
API class will still be verified to still reference the same class name

Thanks,

Scott

>
> Thanks,
>
> Victor.
>
> On 1/6/21 18:52, Scott Marlow wrote:
>>
>> Fyi, the underlying goal is to allow the Jakarta EE TCK signature 
>> tests to be run against newer Java SE versions than the base Java SE 
>> version used to generate the signatures.
>>
>> Some text from the jakartaee-tck/issues/156 tracking issue [1]:
>> "
>>
>> The recorded signatures include every field and method in every class 
>> and
>> interface in the API, as well as the information for every superclass or
>> interface. A consequence of this is that it records the signatures of
>> every JDK class used by the API.
>>
>> That means that a different signature file is needed to test an API on
>> JDK 12 vs JDK 11 (for example), even though the API works identically on
>> both. There's no way to say "this API requires JDK 11 or newer".
>> "
>>
>> With regard to my previous email below asking about the Deprecated 
>> annotation checking, I am wondering if the two different Deprecated 
>> annotation signatures (Java SE 8 vs SE 11) should be considered 
>> compatible since either form (zero, one or two parameters) could be 
>> executed?  If the answer is that it could depend on the behaviour 
>> expected by the user of the SigTest tooling, perhaps an extension 
>> could be introduced.
>>
>> Scott
>>
>> [1] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156
>>
>> On 1/6/21 1:44 PM, Scott Marlow wrote:
>>>
>>> Hi Victor,
>>>
>>> On 1/5/21 5:33 PM, victor.rudometov at oracle.com wrote:
>>>> Hi Scott,
>>>>
>>>> I would eliminate -exclude java in your setup command making it:
>>>>
>>>> 4.  java -Xmx2g -jar $SIGTEST/sigtestdev.jar Setup -classpath 
>>>> jakarta.persistence-api-3.0.0.jar:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/jre/lib/jce.jar 
>>>> -filename /tmp/jakarta.persistence-api-3.0.0.sig -package jakarta
>>>>
>>>> So the file will store signatures of super classes and interfaces 
>>>> as well (from java* packages).
>>>>
>>>> When running the test -package jakarta option will limit testing to 
>>>> jakarta package and subpackages. It will check members and super 
>>>> classes (so no Map instead of Object is allowed).
>>>
>>>
>>> Thanks, I am trying this now.  It seems to be an improvement.
>>>
>>> However, when generating signatures on Java SE 8 but testing on Java 
>>> SE 11, I cannot seem to ignore/exclude Deprecated annotation that 
>>> changed in Java SE 9.
>>>
>>> The Java SE 8 signature for the jakarta.persistence.Persistence 
>>> class contains:
>>>
>>> "  anno 0 java.lang.Deprecated()
>>> "
>>>
>>> The Java SE 11 signature for the jakarta.persistence.Persistence 
>>> class contains:
>>>
>>> "anno 0 java.lang.Deprecated(boolean forRemoval=false, 
>>> java.lang.String since="")
>>> "
>>>
>>> When running the test command on Java SE 11 with the signature 
>>> generated under Java SE 8 I see:
>>>
>>> "Class jakarta.persistence.Persistence
>>>   Missed Annotations
>>>     PERSISTENCE_PROVIDER:anno 0 java.lang.Deprecated()
>>>     providers:anno 0 java.lang.Deprecated()
>>>   Added Annotations
>>>     PERSISTENCE_PROVIDER:anno 0 java.lang.Deprecated(boolean 
>>> forRemoval=false, java.lang.String since="")
>>>     providers:anno 0 java.lang.Deprecated(boolean forRemoval=false, 
>>> java.lang.String since="")
>>>     finalize():anno 0 java.lang.Deprecated(boolean forRemoval=false, 
>>> java.lang.String since="9")
>>> "
>>>
>>> Is there any SigTest magic built in to ignore the Deprecated 
>>> annotation changes?
>>>
>>>
>>> Thanks,
>>> Scott
>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Victor.
>>>
>>>
>>>
>