| Re: [jakartaee-tck-dev] Relaxing signature testing |
So let's take a step back for a moment.
One of the things that led to the success of Java EE was its strict conformance rules which included no super setting. Once you lower the bar and allow “random/selective” annotations, there is no going back.
The JDK team already added fields to the Deprecated annotation in a binary compatible way but they did super set the original Deprecated interface. I think that we need to figure out which super setting changes are allowable and aren't.
IMO this is relevant for solving the jakartaee-tck/issues/156 issue (action is to remove or ignore JDK signatures in signature testing for which I am working on change for).
Some possible options:
1. Ignore only JDK signatures in signature testing.
2. Ignore only JDK annotation signatures in signature testing.
3. Ignore all annotation signatures in signature testing.
IMO the benefit of solving jakartaee-tck/issues/156
is so that TCKs can be run on newer JDK versions than the base JDK
version originally targeted by an EE release. Of course, if a
particular JDK release breaks compatibility, there is no benefit.
When making such an important architectural/platform strategy decision, you need to think carefully of what it could mean 1, 5, 10 years down the road. If you do not take a simple and clear stand on adding vendor specific annotations, where will it end? How will you decide that Vendor A’s annotation is OK, but Vendor B’s annotation is not? What guarantees are there for an API class when vendors are adding their own annotations that there will be no surprises today, tomorrow, or next year?
We need to listen to the community on this IMO. Feedback is
welcome!
Whether an annotation is visible via reflection should not have a bearing on the architectural/platform strategy discussion of adding vendor specific annotations.
I would strongly suggest you spend some time thinking through the overall ramifications of an action such as this. If an annotation is “so compelling” then it should be added to the Jakarta EE Platform vs. allowing vendors to add their favorite annotations to their versions of a Jakarta API JARs.
One of the proposals was to only allow Jakarta EE Platform
annotations to be added.
Once you go down this path, it can be difficult to find your way back so I would not make a hasty decision.
+1 on not making hasty decisions but also we should be open to adjustments as well (like we are doing for jakartaee-tck/issues/156).
Best,
Scott
BestLance
On Mar 18, 2021, at 10:43 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
> Another alternative could be for us to maintain a static list of annotations to ignore. The `annotation ignore list` would only be updated during the development of a Jakarta EE release (e.g. likely via a code change).
That's the alternative that has the slippery slope of when to say when....
---------------------------------------------------
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: Scott Marlow <smarlow@xxxxxxxxxx>
To: jakartaee-tck-dev@xxxxxxxxxxx
Date: 03/18/2021 08:47
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] Relaxing signature testing
Sent by: "jakartaee-tck-dev" <jakartaee-tck-dev-bounces@xxxxxxxxxxx>
On 3/17/21 8:51 PM, Scott Stark wrote: The problem with that is the tooling in this case will never look at that, unless it is also going to be brought under Jakarta.
On 3/17/21 8:51 PM, Scott Stark wrote:
The problem with that is the tooling in this case will never look at that, unless it is also going to be brought under Jakarta.
Since the BND annotations use a RetentionPolicy.CLASS they are not visible via reflection. I don't know if the bytecode for the annotation retains the retention policy setting. It must, else how could the reflection system make the distinction? Is that a sufficient distinction to allow CLASS or SOURCE RetentionPolicy annotations in API jars?
Here is a list of some of the RUNTIME annotations that we would still be verifying { SafeVarargs, Retention, Repeatable, Inherited, Documented, Target, Deprecated } if we were to ignore all CLASS/SOURCE annotations.
Another alternative could be for us to maintain a static list of annotations to ignore. The `annotation ignore list` would only be updated during the development of a Jakarta EE release (e.g. likely via a code change).
On Wed, Mar 17, 2021 at 3:38 PM David Blevins <david.blevins@xxxxxxxxx> wrote:> On Mar 17, 2021, at 12:21 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>
> On 3/17/21 2:48 PM, David Blevins wrote:
>> The flip side is if this is actually adds capabilities desirable in well-known platforms like OSGi, maybe should create a standard annotation and officially add it to the API so everyone has it.
> This is the fundamental question, whether to ignore certain annotations that have no impact on compatibility. This is also somewhat of a slippery slope as the annotation class could be enhanced in a way that does cause compatibility concerns, even if the annotation is a standard annotation.
I intended to say something very different than I think was understood. When I say potentially making it a standard annotation what I mean is a new "jakarta.*" annotation defined in a spec and with signature tests.
-David
_______________________________________________
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://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
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!Kdy9ToD2PDerClo9Z8-Mp4c0E0Yt2Tdi31sGq3uSwuW_oIlG6BpOBWQpLXgVrlaHGw$
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