Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] What are the requirements for TCK Signature testing in the future?

https://github.com/scottmarlow/sigtest/tree/JakartaSignatureTest contains some (hack) changes to (more deeply) ignore the java.* + javax.* classes. 

With these (hack) changes, the updated rule list reflects the current TCK signature testing rules except we are now excluding many  JDK classes:

  1. Do verify that the super class/interfaces (public) contents do not change but exclude 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

We still have more testing to do but IMO we are close to being ready to:

  • Work with the upstream JDK SigTest team on making the JDK SigTest changes in a way that doesn't break JDK team testing of Java SE (https://github.com/openjdk/sigtest/pull/2 is a draft pr to get the conversation started).
  • Or if needed fork SigTest as originally suggested in issue [2] as an alternative.

Scott

On 1/26/21 10:07 PM, Scott Marlow wrote:
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

Back to the top