Source code
package org.junit.validator;
import org.junit.runners.model.FrameworkField;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.TestClass;
import static java.util.Collections.emptyList;
import java.util.List;
/**
* Validates annotations on classes and methods. To be validated,
* an annotation should be annotated with {@link ValidateWith}
*
* Instances of this class are shared by multiple test runners, so they should
* be immutable and thread-safe.
*
* @since 4.12
*/
public abstract class AnnotationValidator {
private static final List<Exception> NO_VALIDATION_ERRORS = emptyList();
/**
* Validates annotation on the given class.
*
* @param testClass that is being validated
* @return A list of exceptions. Default behavior is to return an empty list.
*
* @since 4.12
*/
public List<Exception> validateAnnotatedClass(TestClass testClass) {
return NO_VALIDATION_ERRORS;
}
/**
* Validates annotation on the given field.
*
* @param field that is being validated
* @return A list of exceptions. Default behavior is to return an empty list.
*
* @since 4.12
*/
public List<Exception> validateAnnotatedField(FrameworkField field) {
return NO_VALIDATION_ERRORS;
}
/**
* Validates annotation on the given method.
*
* @param method that is being validated
* @return A list of exceptions. Default behavior is to return an empty list.
*
* @since 4.12
*/
public List<Exception> validateAnnotatedMethod(FrameworkMethod method) {
return NO_VALIDATION_ERRORS;
}
}
Run 1
The code is exceptionally readable due to its clear, logical structure: the class purpose is documented, fields and methods are grouped sensibly, and each method follows a parallel pattern. There is no nesting, and each method performs a single action, returning a shared empty list constant, demonstrating concise, unambiguous intent. Javadoc is thorough and explains both the default behavior and thread-safety considerations. The reading flow is natural, with class-level documentation followed by a private field and three straightforward public methods. Minor style points include a stray blank line between the return statement and closing brace in the field validation method, and the class-level Javadoc missing a period after '@link ValidateWith'. These are cosmetic and do not meaningfully detract from readability. Overall, the code is a strong example of clean, maintainable structure with minimal complexity.
Run 2
The code is highly readable with a clear, logical structure. The class is well-organized with a single responsibility, and the methods are flat with no nesting. Each method serves a clear purpose, returning the same static empty list, and the code is concise. The Javadoc comments are informative and consistent, enhancing intent clarity. There are minor issues: an extra blank line between the class declaration and the field, and a stray blank line inside validateAnnotatedField before the closing brace, which slightly disrupt the natural flow. These are trivial and do not significantly impact readability.
Run 3
The code is highly readable. It demonstrates excellent logical organization with a clear class purpose, well-defined methods, and meaningful names. The structure is flat with no nesting, and intent is unambiguous through clear method names and Javadoc. The code is concise without being overly terse. Each method performs a single action (returning the default empty list). Reading flow is natural due to consistent ordering of methods and standard formatting. Minor deductions: the private static field could have a comment (though its name is clear), and the blank line before the closing brace in the second method is slightly inconsistent. Overall, the code follows strong conventions and is easy to understand.
Run 1
Code Structure: Logically organized around a shared constant and three clearly separated validation methods. Nesting: Flat method bodies with no conditional or loop nesting. Clarity of intent: Descriptive names and Javadoc clearly explain the validation hooks and default empty-list behavior, although the class summary omits field validation. Code length: Implementations are concise; repeated documentation is somewhat verbose but useful for public API methods. Action granularity: Each method performs a single return action on its own line. Reading flow: Consistent method ordering and formatting make the code easy to scan. Minor distractions include unconventional import grouping and an extra blank line in validateAnnotatedField.
Run 2
Code Structure: Clearly organized around three parallel validation methods and a shared empty-result constant. Nesting: Entirely flat, with no conditional or loop complexity. Clarity of intent: Descriptive class, method, and constant names plus Javadoc make the purpose and default behavior explicit, although the class description omits field validation. Code length: Implementations are minimal; repetitive documentation adds some length but supports API readability. Action granularity: Each method contains a single return statement, with one action per line. Reading flow: Consistent method layout makes the code easy to scan; mixed import grouping and an extra blank line in validateAnnotatedField are minor distractions.
Run 3
Code Structure: Clearly organized around three parallel validation methods and a shared constant. Nesting: No nested control flow; all methods are flat. Clarity of intent: Descriptive names and Javadoc clearly explain validation targets, default behavior, and thread-safety expectations. Code length: Implementations are minimal, although repeated documentation adds some verbosity. Action granularity: Each statement performs a single action on its own line. Reading flow: Consistent method ordering and formatting make the class easy to scan. Minor distractions include fragmented import grouping, an extra blank line in validateAnnotatedField, and class-level documentation mentioning classes and methods but omitting fields.