How can I validate two or more fields in combination?

For multiple properties validation, you should use class-level constraints. FromBean Validation Sneak Peek part II: custom constraints:

Class-level constraints

Some of you have expressed concernsabout the ability to apply aconstraint spanning multipleproperties, or to express constraintwhich depend on several properties.The classical example is addressvalidation. Addresses have intricaterules:

• a street name is somewhat standard and must certainly have a length limit
• the zip code structure entirely depends on the country
• the city can often be correlated to a zipcode and some error checking canbe done (provided that a validationservice is accessible)
• because of these interdependencies a simple property level constraint doesto fit the bill

The solution offered by the BeanValidation specification is two-fold:

• it offers the ability to force a set of constraints to be applied before another set of constraints through theuse of groups and group sequences.This subject will be covered in thenext blog entry
• it allows to define class level constraints

Class level constraints are regularconstraints (annotation /implementation duo) which apply on aclass rather than a property. Saiddifferently, class-level constraintsreceive the object instance (ratherthan the property value) in isValid.

@AddressAnnotation public class Address {    @NotNull @Max(50) private String street1;    @Max(50) private String street2;    @Max(10) @NotNull private String zipCode;    @Max(20) @NotNull String city;    @NotNull private Country country;        ...}@Constraint(validatedBy = MultiCountryAddressValidator.class)@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)public @interface AddressAnnotation {    String message() default "{error.address}";    Class<?>[] groups() default { };    Class<? extends Payload>[] payload() default { };}public class MultiCountryAddressValidator implements ConstraintValidator<AddressAnnotation, Address> {    public void initialize(AddressAnnotation constraintAnnotation) {    // initialize the zipcode/city/country correlation service    }    /**     * Validate zipcode and city depending on the country     */    public boolean isValid(Address object, ConstraintValidatorContext context) {        if (!(object instanceof Address)) {            throw new IllegalArgumentException("@Address only applies to Address");        }        Address address = (Address) object;        Country country = address.getCountry();        if (country.getISO2() == "FR") {            // check address.getZipCode() structure for France (5 numbers)            // check zipcode and city correlation (calling an external service?)            return isValid;        } else if (country.getISO2() == "GR") {            // check address.getZipCode() structure for Greece            // no zipcode / city correlation available at the moment            return isValid;        }        // ...    }}

The advanced address validation ruleshave been left out of the addressobject and implemented byMultiCountryAddressValidator. Byaccessing the object instance, classlevel constraints have a lot offlexibility and can validate multiplecorrelated properties. Note thatordering is left out of the equationhere, we will come back to it in thenext post.

The expert group has discussed variousmultiple properties supportapproaches: we think the class levelconstraint approach provides bothenough simplicity and flexibilitycompared to other property levelapproaches involving dependencies.Your feedback is welcome.

To work properly with Bean Validation, the example provided in Pascal Thivent's answer could be rewritten as follows:

@ValidAddresspublic class Address {    @NotNull    @Size(max = 50)    private String street1;    @Size(max = 50)    private String street2;    @NotNull    @Size(max = 10)    private String zipCode;    @NotNull    @Size(max = 20)    private String city;    @Valid    @NotNull    private Country country;    // Getters and setters}

public class Country {    @NotNull    @Size(min = 2, max = 2)    private String iso2;    // Getters and setters}

@Documented@Target(TYPE)@Retention(RUNTIME)@Constraint(validatedBy = { MultiCountryAddressValidator.class })public @interface ValidAddress {    String message() default "{com.example.validation.ValidAddress.message}";    Class<?>[] groups() default {};    Class<? extends Payload>[] payload() default {};}

public class MultiCountryAddressValidator        implements ConstraintValidator<ValidAddress, Address> {    public void initialize(ValidAddress constraintAnnotation) {    }    @Override    public boolean isValid(Address address,                            ConstraintValidatorContext constraintValidatorContext) {        Country country = address.getCountry();        if (country == null || country.getIso2() == null || address.getZipCode() == null) {            return true;        }        switch (country.getIso2()) {            case "FR":                return // Check if address.getZipCode() is valid for France            case "GR":                return // Check if address.getZipCode() is valid for Greece            default:                return true;        }    }}

A custom class level validator is the way to go, when you want to stay with the Bean Validation specification, example here.

If you are happy to use a Hibernate Validator feature, you could use @ScriptAssert, which is provided since Validator-4.1.0.Final. Exceprt from its JavaDoc:

Script expressions can be written in any scripting or expression language, for which a JSR 223 ("Scripting for the JavaTM Platform") compatible engine can be found on the classpath.

Example:

@ScriptAssert(lang = "javascript", script = "_this.value1 != null || _this != value2)")public class MyBean {  private String value1;  private String value2;}