| Re: [jakartaee-tck-dev] What are the requirements for TCK Signature testing in the future? |
|
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.
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? Does the EFSP etc. require a no super-setting rule? Thanks
From: jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx>
On Behalf Of Scott Marlow 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 |