Adam Bien wrote:
>> It's good that vendor-specific annotations can be ignored at runtime.
>> Still, if we introduce vendor-specific annotations, we need to make it
>> clear that they are not portable.
>
> I think the import like org.glassfish.annotation makes it clrear, that a
> certain annotation/extension is not portable.
Yes, but it doesn't distinguish the ones that can be ignored from the
ones that are essential to the functioning of the application.
>> Vendor-specific annotations for otherwise portable concepts might be a
>> good way to prototype annotations that we would want to add to a future
>> version of the spec.
>
> ...and in case they are good enough -> they could integrated into the
> "standard".
Right. And we might learn from our mistakes and do something better
in the standard.
>> Vendor-specific annotations for vendor-specific features fall into two
>> categories:
>>
>> - features that can be safely ignored on other products
>
> A feature of the above category is propably useless :-)
Not at all. I think there's a fair number of configuration items
that are "tuning" or "advice" for which the application will work
correctly, although perhaps with lower performance, if they're not
set.
>> - features that can't be ignored on other products because the
>> application
>> won't function correctly without use of the feature.
>>
>> I wish we had the "ignore at compile time" option for the first kind.
>>
>> The second kind needs very clear documentation so that people understand
>> they're depending on a non-portable feature. As long as we have clear
>> documentation, I don't have any problem adding such annotations.
>
> I think the package import is also a kind of documentation. Such
> annotations could be also deployed in a separate jar....
I think the javadocs need to be very clear about this as well.