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.
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?
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.
Once you go down this path, it can be difficult to find your way back so I would not make a hasty decision.
Best
Lance
>
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
|