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

[victor.rudometov at oracle.com]

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,

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.
>>
>>
>>