This rule raises an issue when a Bean Validation constraint annotation (such as @NotNull, @Size, @Min, @Pattern, etc.) is placed on a static field.

Why is this an issue?

In Java, class-level members are referred to as static fields and static methods. The Bean Validation framework (such as Hibernate Validator) will ignore constraints placed on any members declared with the static keyword.

For example, consider this configuration class:

class Configuration {
    @NotNull
    static String apiKey;

    static void setApiKey(String key) {
        apiKey = key;
    }
}

The @NotNull constraint on the apiKey field will never be evaluated by the Bean Validation framework because the field is declared as static. This means that apiKey could be set to null without any validation error being raised, potentially leading to runtime errors elsewhere in the application.

Bean Validation is designed to work with object instances and their state. Static fields belong to the class itself, not to any particular instance, so they fall outside the scope of Bean Validation’s validation lifecycle.

What is the potential impact?

When Bean Validation constraints are placed on static fields, developers may have a false sense of security, believing that the values are being validated when they are not. This can lead to several issues:

• Runtime errors: Invalid values that should have been caught by validation may cause NullPointerException or other exceptions at runtime.
• Security vulnerabilities: Missing validation on configuration values (such as API keys or endpoints) could allow malicious or malformed data to be used.
• Data integrity problems: Invalid static configuration values may lead to incorrect application behavior or corrupt data processing.
• Maintenance confusion: Future developers may waste time debugging why validation constraints aren’t working as expected.

How to fix it

Move the constraint to an instance field. This is the most straightforward solution and aligns with how Bean Validation is designed to work.

Code examples

Noncompliant code example

public class User {
    @NotNull
    private String username;

    @NotNull  // Noncompliant
    private static String defaultRole;
}

Compliant solution

public class User {
    @NotNull
    private String username;

    @NotNull
    private String role;

    public User() {
        this.role = "USER"; // Set default in constructor
    }
}

Resources

Documentation

• Jakarta - Jakarta Bean Validation specification
• Hibernate Validator - Field-level constraints