Optionally flags code that has finished API.
Optionally flags code that has finished implementation.
Optionally flags code that has finished javadoc.
Optionally flags code that has finished tests.
Flags code that has unfinished API.
Flags code that has unfinished implementation.
Flags code that has unfinished javadoc.
Flags code that has unfinished tests.
Flags code that does not have any javadoc at all.
Flags code that does not have any tests at all.
Flags code that has almost no API.
Flags code that has almost no implementation.
Flags code that has almost no javadoc.
Flags code that has almost no tests.
Four development stages (or levels of quality) are recognized:
No*- if that kind of content does not exist at all
Stub*- if only short placeholder exists
Draft*- if something is unfinished (regardless of how much)
Complete*- if that kind of content is finished (default)
The following kinds of content have predefined annotation types:
*Api- APIs, i.e. signature and semantics of public types and members
*Code- implementation code, i.e. all code behind APIs
*Tests- tests, usually unit tests
*Docs- javadoc, perhaps also external docs (presumably linked from the javadoc)
There are no
NoApi annotation, because they have no meaning and
DraftApi annotations should be used in their place instead. Nuances in meaning can be clarified in string parameter that is taken by all annotations. Applications/libraries are free to define their own annotation types, but the above listed ones are expected to be supported by scanning tools.
Annotations have the default retention
RetentionPolicy.CLASS. Tools can scan for these annotations in sources, during annotation processing, and in compiled class files. Annotations also show up in javadoc for annotated code, so that users are informed about development stage of the class/method they are using.
Copyright © 2020 Robert Važan. All rights reserved.