Just replying to this one:

== Constraint on non parameterized containers
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 where this requirement is coming from. Wouldn't it simply be addressed by providing a validator for @Min + IntegerContainer? I.e. do we need any explicit support for this at all compared to what's possible today?

Also the JavaFX case (your 2nd example around StringProperty) could be satisfied by just adding explicit validators for StringProperty, IntegerProperty etc. Agreed it's not as elegant/generic and wouldn't work for custom types. May still be a way forward, though.

2016-11-21 14:28 GMT+01:00 Emmanuel Bernard <emmanuel@hibernate.org>:

On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers@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:

private ConvertableInteger<Date> myValue;

And now we end in 2 different ways how we annotation value wrappers:

private CachableValue<@NotEmpty String> myCachedValue;

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> {

    public int getValue() { return value; }

    public Date getConvertedValue();

class SomeClass {
    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.


beanvalidation-dev mailing list