Hi Kevin (and Scott)
Lance,
We
might have been the vendor that complained about the @Deprecated vs @deprecated... ;-)
Ha! Names withheld to protect the innocent😜
In
any case, although I agree that the API signature tests are a necessary evil, I wonder if there is some flexibility to include these "non-functional" annotations?
I think this can become a dangerous precedent and potentially lead to issues.
We
would need some process in place to determine which of these annotations are okay to use. And, would we allow this file of allowed annotations to be modified via a TCK challenge? There is some process that we would have to figure out, but on the surface,
this seems like something to explore.
My
only concern is that this is a slippery slope... That is, what is the argument for not eventually allowing "functional" annotations, if they are vendor-specific? For example, what if we introduced the @DoThisInstead annotation to be included in a homegrown
API? The API itself is still the same as what is defined in the Specification, but we provided this additional annotation to spice it up. How do we prevent this down the line?
Right where does it stop and what are the potential issues down the road?
I really think this needs a lot of thought and discussion before trying to do this to really think this through
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From:
Lance
Andersen <lance.andersen@xxxxxxxxxx>
To:
jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date:
03/17/2021
12:20
Subject:
[EXTERNAL]
Re: [jakartaee-tck-dev] Relaxing signature testing
Sent
by: "jakartaee-tck-dev"
<jakartaee-tck-dev-bounces@xxxxxxxxxxx>
API
signatures should match exactly what the spec requires nothing more nothing less. Vendors who provide their own API jars, should not include extra Annotations in their API jar for a Jakarta technology. We have had similar issues in the
API signatures should match exactly what the spec requires nothing more nothing less. Vendors who provide their own API jars, should not include extra Annotations in their API jar for a Jakarta technology.
We
have had similar issues in the past for example where a Java EE licensee added the @Deprecated annotations to a Java EE API which only had the javadoc @deprecated tag causing the signatures to fail.
Best,
Lance
On
Mar 17, 2021, at 12:48 PM, Mark Thomas <markt@xxxxxxxxxx>
wrote:
On
17/03/2021 16:29, Lance Andersen wrote:
If
compatibility is still of the same importance as it was for Java EE, then there should not be any extra annotations/APIs that are vendor specific that are included within the signatures.
Maybe this is less of a concern now for Jakarta EE, I hope not?
There are annotations, such as this BND annotations, that may be used at build time and have zero impact on runtime behaviour and/or compatibility.
For this specific case, what are your compatibility concerns regarding ignoring the annotation when performing the signature test for the TCK?
Mark
On
Mar 17, 2021, at 12:21 PM, Mark Thomas <markt@xxxxxxxxxx<mailto:markt@xxxxxxxxxx>>
wrote:
Hi,
I'd like to propose we relax the signature testing for some specific scenarios.
This proposal was triggered by this TCK issue:
https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-tck/issues/643__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbGz9Ya7Xg$<https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jakartaee-tck/issues/643__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbGz9Ya7Xg$>
Vendors providing their own API JARs may wish to add annotations such as aQute.bnd.annotation.spi.ServiceConsumer which are required if using BND to generate correct OSGI metadata.
These annotations have no runtime impact and are, effectively, transparent to API clients.
Conversely, it is possible an API project could add such an annotation but a vendor providing their own API does not.
The proposal is that we create a list of annotations that should be ignored when performing the signature tests for the TCK.
The initial list (based on those Tomcat 10 is currently using) of proposed annotations to ignore is:
aQute.bnd.annotation.spi.ServiceConsumer
Annotations would have to be confirmed as having no runtime impact before they could be added to this list.
The alternative approach, in this instance, is to add these annotations to the Jakarta provided API JARs and require any vendor provided API JARs to use the same annotations. However, I suspect that there will be other annotations associated with other build
time tools that will fall into this category over time and that it will not always be appropriate to include the annotation in the Jakarta provided API JARs.
Thoughts?
Mark
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx<mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!JDIVVevsMyZU9HI-9ALn_ZBJ-4gDNIceBhrjpxz47LCu_zqiUbm-YBGqwbHJJwrpZA$
Lance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx<mailto:Lance.Andersen@xxxxxxxxxx>
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!IS3Jb08h9onTHR0W2I-xNMZt8JvX2wxUcWh2UEsINQSbGZKxeCONEtvVdQbBXPV4bA$
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!IS3Jb08h9onTHR0W2I-xNMZt8JvX2wxUcWh2UEsINQSbGZKxeCONEtvVdQbBXPV4bA$
<Mail Attachment.gif>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev
mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To
unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!M_AcLLp0R3GSVTgb3wmgXYijReg_iJJdJ3i7u6l2imTcvqMWQuCbuzs_hy3l1qISag$
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
|
