ConstraintValidator as an annotation means that the annotations and the implementation of their validator are coupled.

This means that someone attempting to publish a jar just specifying the common API would be publishing annotations that point to an implementation of the constraint. This could cause problems with multiple implementations of the JSR.

A possible resolution to this is to have the annotations just annotated themselves with say @Validator, and ConstraintFactory take the annotation rather than the constraint class.

I disagree that this is a tight coupling (annotations do not have behavior semantics, they are just benign metadata). It is trivial to compile with a replaced annotation jar.

In any event, you can use xml instead of annotations to bind the validator if this is uncomfortable to you.

Also, there is a constraint factory for integration with third-party dependency injection libraries like Guice, and others, which uses the class as a key to retrieve the instance. Depending on the factory implementation the constraint could refer to an abstract class or interface (with no impl details).

The metadata to constraint is analogous to marking an interface with the implementing class for the system. It certainly makes a user implementing a new constraint easier, but makes 'standard' annotations need to have either standardized implementations or per-vendor implementation packages.

To put another way, it could also be considered analogous to dropping the ConstraintValidator classname completely and requiring the annotations to instead have an inner class called ConstraintImpl that implements them.



(Since ConstraintFactory today has no tie into validator or any other part of the system, I'll assume that will be possible later)

Yes, there are ways around this, but they are very gross. I would have to have a constraint factory that knows the per-vendor implementation details to know which class type to return a different implementation for. This is why I suggested having the factory instead take the annotation itself.

For standardized constraints, I would expect an implementation to know its implementation of the constraint validators anyway. Perhaps making the ConstraintValidator class parameter optional, so it could be omitted for standards-defined constraints?

Actually this is not entirely true. Becasue @constraintValidator is an interface, it will not result in a CNFE at runtime (you still need the class at compile time though).

WRT the standard annotations, you are correct and we are talking about introducing some XML mechanism to softly link an annotation to a constraint implementation. The primary goal is to allow the spec to declare built-in annoations but let the different providers to bring their own implementation (less bug in the spec :) ).



See my comment above. Note that providing the annotation to the constraint factory is not a good approach as it would externalize the discovery mechanism: this mechanism should be well defined and standardized which mean handled by the bean validation provider.

Let's dream a bit.
In a perfect world, I would like the @ConstraintValidator annotation to be reversed and placed on the implementation rather than the annotation constraint. But it requires to either:
- list all the constraint implementations in an XML file
- do some kind of scanning

The scanning does not work for this spec as there is not well defined scope to look at.

Excellent.



Ahh, so a ConstraintFactory should only know about creation and not discovery, and there isn't a plan to create an extensible discovery mechanism (at least in the specification) because that goes contrary to having standard mechanisms.



Both ways seem fine, but reversing the flow would increase the need for a discovery mechanism (to specify which Constraint class to choose for a particular annotation that both support).

I am not categorically opposed to a pluggable discovery mechanism, but unless someone comes with a compelling use case...

I like how JSR 223 (Bean Scripting) handles the discovery. It would allow you to run multiple validation frameworks concurrently without running into collision issues.

Best Regards,
Richard L. Burton III

What you describe Richard is how to retrieve the validation engine (which we will need to describe in the spec at some point).
What we were talking about is how to map a constraint annotation to it's implementation.

OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.

OK, sorry about the mix up.

I hate to throw my 2 cents out there, but I tend to lean toward convention in this case. Grails shows how powerful convention over configuration can be. Instead of decorating a given annotation with yet another annotation, what about applying a naming convention.

E.g.,

@javax.validation.annotations.Nullable expects a class located javax.validation.annotations.NullableValidator that implements the JSR interface.

Because contrary to Grails we can use a plain type safe IDE that points us in one click to the implementation :)

Remember, Grails makes heavy uses of Convention over configuration (CoCo ? :) ) because:
- it had no real way to express metadata in the code (namely no annotation): annotation support in Groovy came later.
- they rely on a dynamic language

Anyway, we are talking about one line of code.

oh an you need the annotation anyway to mark an annotation as a constraint annotation

Hello,

Will I be able to create a costume annotation not requiring writing a costume constraint, that i would be able to do something like:

AddressLine.java:


Bean.java:


the idea is to have a composite annotation out of most simple already provided ones without having to write an implementation class for it as explained in your 2d blog post about the jsr.

Best Regards
Daoud AbdelMonem Faleh

I totally agree that its just one line of code and nothing major. Convention over configuration I believe is powerful. It leans itself to being more productive by reducing the amount of configuration needed.

It people started to use CoCo :) over XML and other means of expressing configuration early on, frameworks wouldn't be so complex :)

Best Regard,
Richard L. Burton III

The idea is very interesting, we started to explore the idea a little while ago in the group. The main concern is about parameters, what if I want to parameterize the meta annotations?