[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Jakarta EE 9.1 + SigTest changes (still work in progress)...
|
I do like the idea of instead using
the JDK `ct.sym` file and we would specify the (to be added)
sigtest `--release 8` option for Jakarta EE 9.1 so that we always
compare against the `JDK 8` classes. We would be relying on
internal JDK information that could go away in the future in which
case we might reconsider the [2] approach or switching to a
`binary compatibility` approach.
Thoughts?
Scott
On 4/7/21 3:57 PM, Scott Marlow wrote:
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]
- The Jakarta EE 9.1 TCKs should work on JDK 8, JDK 11 + JDK
16, all using the JDK 8 signature files.
- Certain JDK annotations are compared only by name (e.g. see
example).
- We will still ensure that no SPEC API sub/super setting
occurs.
- 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/