Re: [jakartaee-tck-dev] Relaxing signature testing

[Scott Stark <starksm64@xxxxxxxxx>]

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?

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