If you could get the tool support there, then I could definitely see a reason for the annotations. Without the tool support though, it just seems like unnecessary documentation bloat.
On Mon, Feb 10, 2014 at 2:56 PM, Thomas Neidhart <[email protected]>wrote: > On 02/10/2014 05:44 PM, Chris wrote: > > Hi Thomas, > > > > If this is only for documentary purposes, it seems a bit strange in my > > mind. Wouldn't a comment at the header serve the same purpose? > > right now it would mainly be used for documentation purposes as tool > support is not yet there. Instead of browsing through the class javadoc > a user may immediately see the corresponding annotation. > > For the future, I see several benefits: > > * integrate these annotations in our currently used build-tools, e.g. > clirr could be instructed to ignore classes that are annotated as > Internal > > * further enhance static code analysis by integrating with tool like > http://types.cs.washington.edu/checker-framework/ > > > On Mon, Feb 10, 2014 at 7:03 AM, luc <[email protected]> wrote: > > > >> Le 2014-02-10 10:16, Thomas Neidhart a écrit : > > [snip] > > >> Would these annotations only be used as documentation or would there be > >> some > >> tools for users? > > See above, right now tool support is quite shallow to my knowledge, but > we have to start somewhere. Ideally, we could create a component that > contains various annotations that are used by commons (e.g. also > repackaging Immutable and ThreadSafe from jcip with RetentionPolicy = > CLASS instead of RUNTIME), and the java ecosystem might start using them. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Chris
