[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] Relaxing signature testing
|
> 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@xxxxxxxxxxxDate:
03/18/2021
08:47Subject:
[EXTERNAL]
Re: [jakartaee-tck-dev] Relaxing signature testingSent
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
