| Re: [jakartaee-tck-dev] Relaxing signature testing |
> 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. 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. -David
Attachment:
smime.p7s
Description: S/MIME cryptographic signature