Bean Validation Sneak Peek part I

Nice, but isn't this just Hibernate Validator with different class and package names?

No it's not :)

Yes the spec has been inspired by Hibernate Validator, XWork, Riffle and other validation frameworks out there. Yes the ideas are converging, that's the whole point of a spec: standardized ideas accepted by a field.

There are the improvements I find most interesting compared to Hibernate Validator:

• the groups feature is interesting to create subsets of validations
• the metadata API will help other libraries to use Bean Validation and its constraint declarations
• it's standardized: other JSRs like JPA can consume the metadata. This will become the common language for validation in the Java land.

It makes a big difference.

I've read the specification and really like it. Groups and metadata are great adds.

However I haven't see a way to add a multiple field validation. E.g.:

public class Bean {
  private Date before;
  private Date afterBefore;
  ...
}

What I want is a way to validate fields before and afterBefore together. Of course I could write a object constraint. However I would like to write:

@MyCustomValidation
public class Bean {
  @Before
  private Date before;
  @AfterBefore
  private Date afterBefore;
  ...
}

public class CustomConstraint implements Constraint<MyCustomValidation>, StandardConstraint {

  public boolean isValid(@Before Objet v1, @AfterBefore Object v2) {
    ...
  }

  public StandardConstraintDescriptor getStandardConstraints() {
    return new StandardConstraintDescriptor() {
       public Class<Annotation>[] getFields() {
          return Arrays.asList(Before.class, AfterBefore.class).toArray();
       }
    };
  }

Could you understand?

Anyway, the specification is superb, a must have.

In page 12 you give best practices to write constraints. Is it possible to write the following and not violate the best practice?

public class AfterCurrentDate implements Constraint<After> {

  public boolean isValid(Date date) {
    return date == null || date.after(new Date());
  }

http://oval.sf.net/ is another great validation framework that supports both on-demand validation and AspectJ integration for aspect-based on-the-fly constraint validation which allows also validating method parameters. It would be really great if you had a look at this framework as well.

I have sent a couple of emails to the JSR comment list, but I have failed to see a list of existing emails. Is it really the case that the comments are not public? I would think it to be useful to make this process open, I am surprised that the JSR process works like this.

OVal is a very nice framework. But only part of it is the main purpose of JSR 303. Contract by design is subject of JSR 305. And the hocks to when the validation should be evaluated is external to the definition of the constraints, i.e., i hope that JEE 5.1 or 6, do this.

how would it work if you have more than one @Before / @AfterBefore in your class?

So far, I have not seen a solution that addresses most use cases aside from an object level validation.

If you refer to the null logic, yes your logic is correct. If the date is null, you return true.

If you refer to the typed parameter then no, you need to accept Object.

The reason behind this choice is that some validator accept multiple types. Object is the only common denominator. If you only accept a sub type (as your example shows), the bean validation implementation must deal with type inconsistency. This is fine in itself but it means type checking is split between the bean validation provider and the constraint implementation. This could lead to inconsistent behaviors.

So far the spec delegates type checking to the implementation.

Oval was very similar to Hibernate Validator last time I checked and has extensions to do programming by contract.

Programming by contract is beyond the scope of the 303 specification mandate, but we are seriously thinking providing extension points in the spec to allow application frameworks that can intercept operations (whether it be a full fledge AOP solution or an interceptor based solution) to plug the JSR 303 core functionalities.

If you want this integrated in Java EE 6, you better start emailing and lobbying the expert group soon :)

I agree with you Stephane, the email solution is not very practical. Let me think about it and find a solution.

If you find more then one annotation in the class, collect all fields and pass as a Array to the constraint. Let's try:

@MyCustomValidation
public class Bean {
  @Before
  private Date before1;
  @Before
  private Date before2;
  @AfterBefore
  private Date afterBefore;
  ...
}

public class CustomConstraint implements Constraint<MyCustomValidation>, StandardConstraint {

  public boolean isValid(@Before Objet v1, @AfterBefore Object v2) {
    ...
    Date[] befores = (Date[]) v1;
    ...
    Date[] after = (Date) v2;
    ...
  }

  public StandardConstraintDescriptor getStandardConstraints() {
    return new StandardConstraintDescriptor() {
       public Class<Annotation>[] getFields() {
          return Arrays.asList(Before.class, AfterBefore.class).toArray();
       }
    };
  }
}

Possible?

But it still delegates. Just add a open type generic to the interface:

public interface Constraint<A extends Annotation, T> {
  void initialize(A constraintAnnotation);
  boolean isValid(T... values);
}

public class AfterCurrentDate implements Constraint<After, Date> {

  public boolean isValid(Date date) {
    return date == null || date.after(new Date());
  }
}

IMHO programming by contract is subject of JSR 305.

Keep us posted :D

The forum has been opened. No more excuse.

Not sure I quite follow your reasoning. Let's follow up on the forum

What I am missing is the possibility to validate an object differently, depending on the current use case. I.e, an account object must be validate differently, if I want to create a new account, or if I want to change that account. So I am not talking about simple syntactic validations but validations depending on the state of the object or some other circumstance.