Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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

Back to the top