7:28 a.m.
On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers(a)me.com>
wrote:
In addition I think that simply adding a constraints annotation to the generic type is
wrong. All examples that we have mentioned are just perfect examples in that the generic
type defines the content. Let’s say we have a class like this:
public abstract class ConvertableInteger<V> {
private int value;
public void setValue(int value) { this.value = value; }
public int getValue() { return value; }
public abstract V getConvertedValue();
}
If you want to validate an instance of this class you normally want to validate the
integer and not the converted value:
private ConvertableInteger<@Min(2_000_000) Date> myValue;
Such an expression looks like if you want to validate a Date object. In this case the
better solution would be something like this:
@Min(2_000_000)
private ConvertableInteger<Date> myValue;
And now we end in 2 different ways how we annotation value wrappers:
private CachableValue<@NotEmpty String> myCachedValue;
@Min(2_000_000)
private ConvertableInteger<Date> myIntegerValue;
First off, your specific example does not work as is as the class is abstract. You would
need an explicit subclass (e.g. DateConvertableInteger extends
ConvertableInteger<Date>). And in that situation, The more natural BV approach would
be to do this:
public class DateConvertableInteger extend ConvertableInteger<Date> {
@Min(@2_000_000)
public int getValue() { return value; }
@NotEmpty
public Date getConvertedValue();
}
class SomeClass {
@Valid
private StringConvertableInteger myValue;
}
== overriding constraint declarations
Now if you want a way to override the constraints of an embedded (@Valid) object (graph),
then I think that is a different subject that we can try and address. JPA for example has
the notion of @AttributeOverride. It is more complicated in the case of Bean Validation as
we would need to override actual annotations. Not sure how to express that for now. Do we
think that it is a valid and important requirement?
To clarify, here is what is required
public class Embeddable {
@NotEmpty String foo;
}
public class Entity {
@Valid @Override(path=“foo”, constraints=@Min(3)) // note that this is not valid Java
syntax
Embeddable embeddable;
}
== Constraint on non parameterized containers
That raises another question, the proposal allows to to three things:
- apply constraints on a type use generic declaration(*): Collection<@NotEmpty
String> foo;
- apply constraints on specialized generic parameters (*): @Pattern(…) StringProperty
prop; //where StringProperty extends Property<String>
- apply constraints on container with no generic: @Min(3) IntegerContainer prop; // where
class IntegerContainer{ Integer value; } i.e. no generic
(*) I don’t know the actual proper names so sorry if I butchered notions
I am liking option 3 less and less and as far as I can remember, it does not rely on an
explicitly identified use case. Who is wanting to support that usage, vs restrict the
container feature to parameterized containers?
I’m not sure I was all that clear, so please ask any question if you have any doubt.
Emmanuel