[
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?
|
On 1/27/21 4:13 AM, Steve Millidge
(Payara) wrote:
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.
Historically, we use the no super-setting rule to ensure that
applications are compatible between multiple implementations.
While the goal of issues/156 [2] is to remove Java SE class
information from TCK signature testing, we could consider other
changes.
IMO, this is the right mailing list for expressing opinions about
relaxing/removing rules or tightening them up (and expressing the
"why").
Of course you can change your mind, but for now, I am going to
start tracking opinions such as yours in this email thread for
possible later collection.
Steve Millidge vote: +1 for removing/relaxing `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?
In a best case, there is one or more early access spec
implementation that adds the same early (e.g. still changing) API
methods.
In a worst case, there are multiple early access spec
implementations that may add the same early API methods but also
add others that they think should be included but do not get added
to the specification. The problem here is with adding vendor
specific extension methods/fields, which if used by applications,
reduce compatibility between implementations.
IMO, if we went down this path of removing/relaxing the `no
super-setting` rule, we would need to define other rules to ensure
that vendor extension methods/fields are fair game to be redefined
by the underlying specification in the future. There is probably
much more to consider as well.
Regarding the how we do "code first" spec development for Jakarta
EE 10 with a no super-setting rule, that is a very good question.
IMO, we really need to consider the compatibility impact as
mentioned above but if we kept the no super-setting rule, all EE
10 implementations need to change their spec implementations to
match the final Jakarta EE 10 signatures, before they can consider
their EE 10 implementation to be compatible. In other words, you
can make any API change during development but when the EE 10
specifications are complete and final, all implementations need to
match the final EE 10 signatures.
The above are not really my opinions, I will try to respond
without expressing my opinions at this time.
Scott
Does
the EFSP etc. require a no super-setting rule?
Thanks
Steve
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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
