I've just added a test case for Serializable, which is what Hibernate Tools generates if no more specific type could be determined.

And yes, I would expect HV to use the index based access for such values in the same way as it does for Object.

You are right, adding our own VE is a working solution for us.

Just a few more thoughts:
I have no idea about additional VEs, but the default ones are about 20 for classes (where more than 1/2 is final) and 5 for interfaces.

As for the bag: Why not? The runtime implementation of the bag might well be ordered and/or allow index based access using the List interface.
IMHO "Set" or "Bag" semantics do not prohibit index based access - and if it is available I would love to see the index in the constraints!

And what is the "intention" of the user if he declares "Object"? When I follow your argumentation he has no intention at all in this case and should not expect any VE to be applied!? IMHO everything else would be inconsistent.

Well, keep in mind that VEs are mostly registered for interfaces.

I understand your point of view but I think the fact that we take into account the intention of the user to declare a particular semantic with a type makes sense (let's put aside the fact that it allows some non negligible optimization).

If you choose the semantic of a bag then you can't expect HV to consider your element is an ordered list.

I think, in your case, declaring your own value extractor for your very specific usage is an acceptable trade-off.

Thank you for your time, clarifying the wording, the explanations and the valuable performance hints.

I understand your ideas on the optimizations – but I still think they are going one step too far. I’d like to come back to my thoughts on classes and interfaces with a few examples:

When HV sees Optional as declared type it can safely exclude all other ValueExtrators (except the one for Optional) because none of them is compatible with Optional (Optional is not implementing any interface) and no subclass ever will (Optional it is final).

My general rule of thumb here would be that this is the case for any final class as declared type.

When HV sees ReadOnlyListProperty as declared type it can safely exclude any other ValueExtractor for classes not compatible with this class – like int[], ReadOnlySetProperty, … However, it must not exclude the ValueExtractor for ListProperty as this is a “compatible” class (extending ReadOnlyListProperty) and the runtime type might be exactly this.

IMHO it must also not exclude the ValueExtractor for any interface - because the runtime type might implement exactly such an interface. This means that in this example I would not want to rule out ValueExtractors for Iterable, List, Map, ...– just because it is technically possible for the runtime type to implement any of these interfaces. HV still has to decide based on the runtime type which is the “most specific” extractor – but excluding them in the first place does not reflect the possibilities of the language.
(Yes, I cannot think of any valuable implementation case with the given classes and interfaces – but since it is technically possible one might come up with a valid set of different classes/interfaces which would require support for this.)

The same holds true for Iterable, List, Map as declared type: HV can safely exclude ValueExtractors for int[], Object[], Optional, OptionalInt, etc. as performance optimization just because these are final classes and not implementing the given interface. It is again impossible in this case for the runtime type to be any of those classes.

IMHO it is again not valid to exclude any ValueExtractor for any interface if the declared type is a non-final class or interface. Just because you don’t know what interfaces a runtime subclass might implement.
(A valuable example here is our OrderedSet.)

My general rule of thumb would be: If the declared type is a non-final class or interface HV can sort out ValueExtractors for incompatible classes. However all ValueExtractors for interfaces should remain possible.

The nice/tricky thing with Set and List in our case is that List includes all Set methods just with a different semantics. Thus our OrderedSet can safely implement both interfaces.

Yes, we could declare List or OrderedSet as return types to solve this (though this is not that easy because the given code is generated by Hibernate Tools). And yes, we could solve/work around this by adding our own OrderedSetValueExtractor. But as explained above I more have the feeling that HV is over-optimized here a bit.

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:

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:

as it's the exact semantic I want.