| Re: [jakartaee-tck-dev] Relaxing signature testing |
> On Mar 17, 2021, at 11:48 AM, David Blevins <david.blevins@xxxxxxxxx> wrote: > >> On Mar 17, 2021, at 11:17 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote: >> >> 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? > > This is my main concern. Once we take a lax stance it's really hard to draw a line and stick to it. Every exception will set precedent others will point at to justify why their annotation should also be an exception. The rules will get looser over time and/or we will spend a lot of time arguing. > > I personally do not see the proposed annotation as even non-functional. If it not being present results in missing OSGi metadata that affects use in OSGi, it is affecting runtime capabilities. It may be the case that it is considered a convenience because there are other ways to create the metadata files. If that were the case, my first thought would be then do those other ways and let's not risk adding difficult-to-enforce rule exceptions. My follow up thought would be, can't the tool be improved so that data can be supplied in some other convenient way. To add another potential scenario here. A lot of platforms, Quarkus for example, do quite a lot of work at build-time to generate artifacts used at runtime. The annotations themselves are not used at runtime. I expect this trend to continue and much of what we do at startup in runtime will gradually shift over to build time. Specifications already allow this as aside from CDI extensions "Deployment" can occur a build-time or runtime. All of the early EE implementations did their generation and the majority of their "deploy" work at build-time. To me, the line of "not used at runtime" creates an incredibly large and uncontrollable loophole as there's nothing in our specs or requirements that actually says annotations must be evaluated at runtime. That is simply something we tend to do in practice. -David
Attachment:
smime.p7s
Description: S/MIME cryptographic signature