So, trying to explain more clearly here, hope I'll succeed .

When I talk about a declared type, I'm talking about the one you have in your code, so in your example Set for public Set<...> getDataAsSet().

When I talk about a runtime type, I'm talking about the type effectively returned when executing the code and, in your example, it's OrderedSet.

To be honest, we have to amend the spec about this behavior because we did this adjustment post-spec writing: in the spec, you only consider the runtime type of the object. So if your method has a declared return type of Set but the most specific value extractor for the runtime type is List for whatever reasons, if you follow the spec by the letter, you would expect HV to choose the List based value extractor.

The fact is that:

• it was not really logical as if you declared a Set return type in your code, you would certainly expect a Set semantic, even in HV
• it had pretty bad performances as it required considering the whole set of possible value extractors at runtime. So with this optimization, instead of considering the whole set of possible value extractors (List, Optional, Set, Map, the JavaFX ones and so on), we only consider the ones compatible with the declared type so, in my above example, the ones compatible with Set.

We decided to adjust this behavior in the reference implementation and to amend the spec in 2.1.

> A real surprise just happened when I tried to "fix" this by adding a special OrderedSetValueExtractor: Though OrderedSet is not declared in any of the get-methods in my Model it is still used!? So finding a good extractor at runtime based on the returned type seems to work!

This is because your OrderedSetValueExtractor is compatible with the types you declared (e.g. Set) so it's kept in the list of the value extractor candidates and when we select the most specific one at runtime we choose OrderedSetValueExtractor because it's the most specific.

I hope it's more clear with this explanation.

By the way, for maximum speed, I recommend you to mark with @Valid the type argument:

public Set<@Valid YourBean> getDataAsList()

And another recommendation, if you expect a specific behavior related to OrderedSet I would declare my return types as OrderedSet as it's indeed a specific semantic. So I would end up with the following code:

public OrderedSet<@Valid YourBean> getDataAsList()

as it's the exact semantic I want.