I have read check documentation: https://checkstyle.sourceforge.io/checks/annotation/annotationlocation.html#AnnotationLocation
I have downloaded the latest checkstyle from: https://checkstyle.org/cmdline.html#Download_and_Run
I have executed the cli and showed it below, as cli describes the problem better than 1,000 words
Code:
@Deprecated // Expected Violation
/** This is a documented class. */
public final class Test{
public void doSomething() {
System.out.println("Doing something...");
}
}
Config:
/var/tmp $ cat config.xml
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
"-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
"https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name="Checker">
<property name="localeLanguage" value="en"/>
<module name="TreeWalker">
<module name="AnnotationLocation">
<property name="id" value="ClassAnnotationLocation"/>
<property name="tokens"
value="CLASS_DEF, INTERFACE_DEF, ENUM_DEF, RECORD_DEF"/>
</module>
</module>
</module>
Cli:
/var/tmp $ java -jar checkstyle-10.26.1-all.jar -c config.xml Test.java
Starting audit...
Audit done.
According to the AnnotationLocation documentation:
“Checks location of annotation on language elements. By default, Check enforce to locate annotations immediately after documentation block and before target element...”
However, in the provided example, the annotation @Deprecated is placed before the Javadoc comment, which violates this rule. Still, no violation is reported, despite the documentation clearly stating that annotations must come after documentation blocks.
This suggests an inconsistency between the documentation and the actual implementation of the AnnotationLocation check.
We are aware that this issue can be indirectly detected using the InvalidJavadocPosition check, which flags mislocated Javadoc comments. However, this workaround is not reflected in the documentation of AnnotationLocation, and it shifts the responsibility to a different check module — which can confuse users expecting AnnotationLocation to handle such cases directly.
Suggestions:
If the AnnotationLocation check is intended to enforce annotation placement after documentation blocks, the implementation should be updated to detect such violations.
If not, the documentation should be updated to clarify that this rule is not enforced by AnnotationLocation, and potentially refer users to InvalidJavadocPosition.
Clarifying the scope and behavior would help align user expectations and ensure proper configuration.
I have read check documentation: https://checkstyle.sourceforge.io/checks/annotation/annotationlocation.html#AnnotationLocation
I have downloaded the latest checkstyle from: https://checkstyle.org/cmdline.html#Download_and_Run
I have executed the cli and showed it below, as cli describes the problem better than 1,000 words
Code:
Config:
Cli:
According to the AnnotationLocation documentation:
“Checks location of annotation on language elements. By default, Check enforce to locate annotations immediately after documentation block and before target element...”
However, in the provided example, the annotation
@Deprecatedis placed before the Javadoc comment, which violates this rule. Still, no violation is reported, despite the documentation clearly stating that annotations must come after documentation blocks.This suggests an inconsistency between the documentation and the actual implementation of the AnnotationLocation check.
We are aware that this issue can be indirectly detected using the InvalidJavadocPosition check, which flags mislocated Javadoc comments. However, this workaround is not reflected in the documentation of AnnotationLocation, and it shifts the responsibility to a different check module — which can confuse users expecting AnnotationLocation to handle such cases directly.
Suggestions:
If the AnnotationLocation check is intended to enforce annotation placement after documentation blocks, the implementation should be updated to detect such violations.
If not, the documentation should be updated to clarify that this rule is not enforced by AnnotationLocation, and potentially refer users to InvalidJavadocPosition.
Clarifying the scope and behavior would help align user expectations and ensure proper configuration.