In some situations, a group is a super set of one or more groups. This can be described by Bean Validation. A group can inherit one or more groups by using interface inheritance.

/**
 * Customer can buy without harrassing checking process
 */
public interface BuyInOneClick extends Default, Billable {
}

For a given interface Z, constraints marked as belonging to the group Z (ie where the annotation groups property contains the interface Z) or any of the super interfaces of Z (inherited groups) are considered part of the group Z.

In the following example:

/**
 * User representation
 */
public class User {
    @NotNull
    private String firstname;

    @NotNull(groups = Default.class)
    private String lastname;

    @NotNull(groups = {Billable.class})
    private CreditCard defaultCreditCard;
}

validating the group BuyInOneClick will lead to the following constraints checking:

because Default and Billable are subinterfaces of BuyInOneClick.

By default, constraints are evaluated in no particular order and this regardless of which groups they belong to. It is however useful in some situations to to control the order of constraints evaluation. There are often scenarios where a preliminary set of constraints should be evaluated prior to other constraints. Here are two examples:

To implement such ordering, a group can be defined as a sequence of other groups. Each group in a group sequence must be processed sequentially in the order defined by@GroupSequence.value when the group defined as a sequence is requested. Note that a group member of a sequence can itself be composed of several groups via inheritance or sequence definition. In this case, each composed group must respect the sequence order as well.

Processing a group is defined in Section 3.5, “Validation routine” ; if one of the groups processed in the sequence generates one or more constraint violation, the groups following in the sequence must not be processed. This ensure that a set of constraint is evaluated only if another set of constraint is valid.

Groups defining a sequence and groups composing a sequence must not be involved in a cyclic dependency either directly or indirectly, either through cascaded sequence definition or group inheritance.

Groups defining a sequence should not directly inherit other groups. In other words, the interface hosting the group sequence should not have any super interface.

Groups defining a sequence should not be used directly in constraint declarations. In other words, the interface hosting the group sequence should not be used in a constraint declaration.

To define a group as a sequence, the interface must be annotated with the @GroupSequence annotation.

@Target({TYPE})
@Retention(RUNTIME)
public @interface GroupSequence {
    Class<?>[] value();
}

Here is a usage example

@ZipCodeCoherenceChecker(groups = Address.HighLevelCoherence.class)
public class Address {
    @NotNull @Size(max = 50)
    private String street1;

    @ZipCode
    private String zipcode;

    @NotNull @Size(max = 30)
    private String city;

    /**
     * check conherence on the overall object
     * Needs basic checking to be green first
     */
    public interface HighLevelCoherence {}

    /**
     * check both basic constraints and high level ones.
     * high level constraints are not cheked if basic constraints fail
     */
    @GroupSequence({Default.class, HighLevelCoherence.class})
    public interface Complete {}
}

In Example 3.5, “Make use of group sequence”, when the Address.Complete group is validated, all constraints belonging to the Default group are validated. If any of them fail, the validation skips the HighLevelCoherence group. If all Default constraints pass, HighLevelCoherence constraints are evaluated.

In Example 3.5, “Make use of group sequence”, validating the Default group does not validate HighLevelCoherence constraints. To ensure a complete validation, a user must use the Completegroup. This breaks some of the encapsulation you could expect. You can work around this by redefining what the Default group means for a given class. To redefine Default for a class, place a@GroupSequence annotation on the class ; this sequence expresses the sequence of groups that does substitute Default for this class.

@GroupSequence({Address.class, HighLevelCoherence.class})
@ZipCodeCoherenceChecker(groups = Address.HighLevelCoherence.class)
public class Address {
    @NotNull @Size(max = 50)
    private String street1;

    @ZipCode
    private String zipcode;

    @NotNull @Size(max = 30)
    private String city;

    /**
     * check conherence on the overall object
     * Needs basic checking to be green first
     */
    public interface HighLevelCoherence {}
}

In Example 3.6, “Redefining Default group for Address”, when an address object is validated for the group Default, all constraints belonging to the group Default and hosted on Address are evaluated. If none fails, all HighLevelCoherence constraints present on Address are evaluated. In other words, when validating the Default group for Address, the group sequence defined on the Address class is used.

Since sequences cannot have circular dependencies, using Default in the declaration of a sequence is not an option. Constraints hosted on a class A and belonging to the Default group (by default or explicitly) implicitly belong to the group A.

A sequence defined on a class A (ie. redefining the Default groups for the class) must contain the group A. In other words, the default constraints hosted on a class must be part of the sequence definition.

It is possible to implicitly group some constraints in the same group without explicitly listing such a group in the constraint declaration. Every constraint hosted on an interface Z and part of theDefault group (implicitly or explicitly) belongs to the group Z. This is useful to validate the partial state of an object based on a role represented by an interface.

/**
 * Auditable object contract
 */
public interface Auditable {
    @NotNull String getCreationDate();
    @NotNull String getLastUpdate();
    @NotNull String getLastModifier();
    @NotNull String getLastReader();
}

/**
 * Represents an order in the system
 */
public class Order implements Auditable {
    private String creationDate;
    private String lastUpdate;
    private String lastModifier;
    private String lastReader;

    private String orderNumber;

    public String getCreationDate() {
        return this.creationDate;
    }

    public String getLastUpdate() {
        return this.lastUpdate;
    }

    public String getLastModifier() {
        return this.lastModifier;
    }

    public String getLastReader() {
        return this.lastReader;
    }

    @NotNull @Size(min=10, max=10)
    public String getOrderNumber() {
        return this.orderNumber;
    }
}

When an Order object is validated on the Default group, the following constraints are validated: @NotNull on getCreationDate, getLastUpdate, getLastModifier, getLastReader,getOrderNumber and @Size on getOrderNumber as all belong to the Default group.

When an Order object is validated on the Auditable group, the following constraints are validated: @NotNull on getCreationDate, getLastUpdate, getLastModifier, getLastReader. Only the constraints present on Auditable (and any of its super interfaces) and belonging to the Default group are validated when the group Auditable is requested. It allows the caller to validate that a given object can be safely audited even if the object state itself is not valid.

The formal rules defining groups are as followed. Text in italic are comments about the rules.

For every class X:

When a given group G (represented by an interface G) is requested for the validation of a class X:

When the Default group of a given class X is overridden via @GroupSequence, its validation is as followed:

Unless defined by a @GroupSequence, evaluation ordering is not constrained. In particular, several groups can be validated in the same pass. If a group definition leads to a circular sequencing order between groups, an exception is raised.