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.