Re: [jakartaee-tck-dev] What are the requirements for TCK Signature test

[Mark Thomas <markt@xxxxxxxxxx>]

-1 for removing the no super-setting rule.

Mark


The speculative development
On 27/01/2021 14:35, Scott Marlow wrote:
> 
> On 1/27/21 4:13 AM, Steve Millidge (Payara) wrote:
>>
>> I was wondering about the no super-setting rule. How will we do “code
>> first” spec development for Jakarta EE 10 with a no super-setting rule.
>>
> Historically, we use the no super-setting rule to ensure that
> applications are compatible between multiple implementations.  While the
> goal of issues/156 [2] is to remove Java SE class information from TCK
> signature testing, we could consider other changes. 
> 
> IMO, this is the right mailing list for expressing opinions about
> relaxing/removing rules or tightening them up (and expressing the "why"). 
> 
> Of course you can change your mind, but for now, I am going to start
> tracking opinions such as yours in this email thread for possible later
> collection.
> 
> Steve Millidge vote: +1 for removing/relaxing `no super-setting` rule.
> 
> 
>>  
>>
>> For example if we want to get early access spec implementations out in
>> the open in Payara for feedback we would then cease to be a Compatible
>> Implementation of Jakarta EE as we would fail the signature test?
>>
> In a best case, there is one or more early access spec implementation
> that adds the same early (e.g. still changing) API methods. 
> 
> In a worst case, there are multiple early access spec implementations
> that may add the same early API methods but also add others that they
> think should be included but do not get added to the specification.  The
> problem here is with adding vendor specific extension methods/fields,
> which if used by applications, reduce compatibility between implementations.
> 
> IMO, if we went down this path of removing/relaxing the `no
> super-setting` rule, we would need to define other rules to ensure that
> vendor extension methods/fields are fair game to be redefined by the
> underlying specification in the future.  There is probably much more to
> consider as well. 
> 
> Regarding the how we do "code first" spec development for Jakarta EE 10
> with a no super-setting rule, that is a very good question.  IMO, we
> really need to consider the compatibility impact as mentioned above but
> if we kept the no super-setting rule, all EE 10 implementations need to
> change their spec implementations to match the final Jakarta EE 10
> signatures, before they can consider their EE 10 implementation to be
> compatible.  In other words, you can make any API change during
> development but when the EE 10 specifications are complete and final,
> all implementations need to match the final EE 10 signatures.
> 
> The above are not really my opinions, I will try to respond without
> expressing my opinions at this time. 
> 
> Scott
> 
>>
>>  
>>
>> Does the EFSP etc. require a no super-setting rule?
>>
>>  
>>
>> Thanks
>>
>>
>> Steve
>>
>>  
>>
>> *From:*jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> *On
>> Behalf Of *Scott Marlow
>> *Sent:* 27 January 2021 03:08
>> *To:* jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
>> *Subject:* [jakartaee-tck-dev] What are the requirements for TCK
>> Signature testing in the future?
>>
>>  
>>
>> Hi,
>>
>> Even if you do not want to get your hands dirty with the JDK SigTest
>> project at this time, it would be awesome to hear some feedback on
>> what might be the minimal requirements for signature testing.  More
>> specifically, I spent some time reading the SigTest source with issue
>> [2] in mind and noted some (possible) minimal requirements today [3].
>>
>> IMO, the underlying goal of [2] is to allow the TCK Signature tests to
>> be targeted for a base Java SE version but also for the signatures
>> tests  be possible to pass on newer Java SE versions.  Below is a copy
>> of comment [3]:
>>
>> "
>>
>> Some desired goals for what I am trying to accomplish for this issue:
>>
>> 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
>>
>> "
>>
>> I am at the point of hacking on some JDK SigTest changes [4] and need
>> to work through some issues that I am hitting with the Java SE 8
>> signatures running on a new Java SE version.  Now that I just have a
>> (rough) overview of the SigTest code, I would like to start sharing
>> with the experience of making this change, so others can learn as
>> well.  Perhaps we can record a video of a `SigTest` code walk through
>> soon.
>>
>> If anyone does have feedback on what the minimal TCK signature checks
>> need to be, that would be good to share.
>>
>> I would like to point out that we might be able to do better than I
>> described in #2, but that isn't clear yet.
>>
>> If you have feedback that we should still detect sub/super-setting (#4
>> + #5) or that we shouldn't, please share your opinion/comments.
>>
>> Thanks,
>>
>> Scott
>> [1] https://wiki.openjdk.java.net/display/CodeTools/sigtest
>> [2] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156 "Need
>> improved signature test tool that doesn't include JDK signatures"
>> [3]
>> https://github.com/eclipse-ee4j/jakartaee-tck/issues/156#issuecomment-767836958
>> [4] https://github.com/scottmarlow/sigtest/tree/explore_more_changes
>> [5] https://docs.oracle.com/javase/9/docs/api/java/lang/Deprecated.html
>>
>>
>> _______________________________________________
>> jakartaee-tck-dev mailing list
>> jakartaee-tck-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
> 
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>