Until now I only worked with lists and here the approach is quite nice. Sadly it won’t work always. By adding an constraints annotation to the generic type of the list we know that the annotation mentions the content of the list. But this is only working because of one point: The generic type of a collection defines the type of the collection content. This works fine for collections (and for example JavaFX properties) but in other cases this will end in problems.

Let’s say we have the following 2 interfaces:

public interface CachedValue<V> {
  V getCachedValue();
}

public interface RealValue<V> {
  V getRealValue();
}

Based on this interfaces we can easily create a new class that implements both interfaces:

public class CachableValue<V> implements CachedValue<V>, RealValue<V> {

  private V cachedValue;

  @Override
  public V getCachedValue() {
  return cachedValue;
  }

  @Override
  public V getRealValue() {
  V realValue = receiveValueFromServer();
  cachedValue = realValue;
  return realValue;
  }

  private V receiveValueFromServer() {
  return ServerConnector.getCurrentValue(); //Some fake code
  }
}

Am 18.04.2017 um 14:57 schrieb Emmanuel Bernard <emmanuel@hibernate.org>:

I'm not using JavaFX but I would be in favor of 2. because it let's
people put a size constraint on the List.

Have you considered a blog post to get more feedback. Here people don't
use JavaFX or are shy.

On Wed 17-04-12 16:16, Guillaume Smet wrote:
Hi,

We are refining the value extraction work and one of the remaining tasks is
to throw a proper exception if we have ValueExtractors defined in parallel
hierarchies for a given type.

This led to discovering the below issue with the JavaFX collection types.

Let's take the ListProperty example (we have the same issue with Set and
Map): ListProperty inherits from ObservableValue and from List.

For now, it uses (by chance) the ObservableValue extractor which unwraps
the value by default. So basically:
@NotNull
private ListProperty<String> listProperty = new
ReadOnlyListWrapper<String>( null );
will return a violation.

With the new conflict detection, it will throw an exception as it's unable
to find ONE most specific ValueExtractor as there are 2 valid candidates:
ObservableValueValueExtractor and ListValueExtractor.

If we want to solve the conflict, we need to introduce a specific
ValueExtractor for ListProperty and decide of its behavior.

We have 2 possibilities:
1/ consider ListProperty as an ObservableValue and thus simply unwrap the
list and validate the constraint against the list. In the above example,
@NotNull would then apply to the inner list. Same behavior as explained
above.
2/ consider ListProperty as a List. Thus the value extractor would iterate
over the element of the list. In the above case, it won't return a
violation. In the below example, the @NotNull would refer to listProperty
itself and the constraints on the elements of the list would be validated:
@NotNull
private ListProperty<@Size(min = 3) String> listProperty = new
ReadOnlyListWrapper<String>( null );

Gunnar and I are in favor of 2/ but it changes the current behavior as the
@NotNull would refer to the container instead of referring to the wrapped
value.

We would really like to have some feedback from people using JavaFX.

Thanks!

--
Guillaume

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev