Bill Shannon schrieb:
> 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.
But in the practice if your application behaves differently it is no
more compatible...
In my past projects we had some load testing before production - in case
the performance was too low we didn't deployed the application.
>
>>> - 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.
>
JavaDocs are crucial. I like the Java EE 5 documentation of the
annotations - it's really useful
regards,
adam
--
Dipl. Inf. adam bien
BEA Technical Director
Sun Certified Java Programmer
Sun Certified Enterprise Java Architect
Sun Enterprise Java Trainer
Mobile: 0049(0)170 280 3144
eMail: abien_at_adam-bien.com
Homepage: www.adam-bien.com
Weblog: http://www.adam-bien.com/roller/page/abien
----------
Book author:
Enterprise Architekturen
entwickler.press 2006
ISBN: 393504299X
and Enterprise Java Frameworks,
J2EE Patterns, J2EE HotSpots and Struts.