I have written about writing a custom annotation before and that post discussed how to create corresponding custom IDE inspections in NetBeans 8.0.2 and IntelliJ IDEA 14.0.3 for this custom annotation. If one is not using the library with the annotation for any other reason, it can seem a bit heavy to add a new library dependency simply for an annotation when it's relatively straightforward to write one's own custom annotation. Other considerations when using a third-party library's annotation is that the third-party library must be included on one's classpath and that there is typically no out-of-the-box support in the most popular Java IDEs to indicate special treatment of the construct annotated with the annotation. I talked more about this annotation in the blog post " Two Generally Useful Guava Annotations". This explanation of the use of seems to imply this is a good fit for a "new" construct that may be removed.
Note that the presence of this annotation implies nothing about the quality or performance of the API in question, only the fact that it is not "API-frozen." An API bearing this annotation is exempt from any compatibility guarantees made by its containing library. The Javadoc documentation for Guava's annotation states: Signifies that a public API (public class, method or field) is subject to incompatible changes, or even removal, in a future release.
I have occasionally run into a situation in which I have needed to introduce a new API or construct for others to try out, but have known that it might change based on others' feedback after some use of it.
0 kommentar(er)
