Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-tck-dev] Jakarta EE 9.1 + SigTest changes (still work in progress)...

We have a few options for addressing issues#156 [1] which I would like more input on.  Quoting from [1]:

"There are some features in the sigtest tool that seem like they should work to limit the recorded signatures to only the API being tested, or to exclude the signatures for JDK classes, but these features have never worked the way I wanted them to work."

[2] is a minimal change to allow the Platform TCK signature testing to specify a list of JDK classes that should be ignored (note that the list is currently hard coded as part of [2]).  [2] will be updated to include two new command line options for specifying the list of JDK packages to ignore and the JDK class names to ignore.

Why don't we just ignore all JDK classes via "javax.*" + "java.*"?  The short answer is that some of the JDK classes still need to used in signature testing and not ignored.  The longer answer is that we have some options as to how we could do that differently but would involve refactoring much of the SigTest tooling.

Before I explain what needs to be refactored, I will summarize what we will get out of [2] (with a few more changes and more testing).

Summary of what we get from [2]

  1. The Jakarta EE 9.1 TCKs should work on JDK 8, JDK 11 + JDK 16, all using the JDK 8 signature files.
  2. Certain JDK annotations are compared only by name (e.g. see example).
  3. We will still ensure that no SPEC API sub/super setting occurs.
  4. From the [1] description which I quoted above, we are addressing "or to exclude the signatures for JDK classes".

The SigTest tooling does have other options that only verify binary compatibility (please see comments [3][4] that discuss how OSGi tooling verifies binary compatibility).  Historically, we have always required no API sub/super setting.  If we switched to a binary compatibility approach, we would need new rules about super setting that wouldn't be enforced by the signature testing (at least I don't expect they would).  This thread isn't so much about discussing binary compatibility.  I'm just mentioning this idea now as I think it could give us more flexibility to better support future JDK versions than we currently have.

Call to action

Speak up if you have input about the [2] change for addressing [1].  Also be aware that we will be looking for a quick turn around on producing a SigTest release that includes [2] once we add the -IgnoreJDKPackage=package + -IgnoreJDKClass=class options.

[5] shows that with the change, we are passing the Jakarta EE Platform TCK signature tests on JDK 11 (using the JDK 8 signature map files).  I haven't yet tried running the Standalone TCKs with these changes yet but that will be coming soon.

Scott

[1] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156
[2] https://github.com/jtulach/netbeans-apitest/pull/2
[3] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156#issuecomment-740961999
[4] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156#issuecomment-755564193
[5] https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck-scottmarlow/job/sigtest_netbeans-script-part2/2/

Back to the top