[bv-dev] Conflict issue with value extraction and JavaFX collection types

[Hendrik Ebbers]

I think this is not a JavaFX specific problem. This can happen everywhere if you have defined extractors for 2 interface types and and have an implementation of both. 
In this specific example I would prefer to define ListProperty as a List.

In general I think that this problem might / will happen in other frameworks and APIs, too.

I added such an example in a mail about the usage of annotations in the generic information:

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170419/ef51b453/attachment.html