Bugfix (active with new BeansWrapper(new Version(2, 3, 21))): In many cases, less specific hint class was used for unwrapping than that was theoretically possible within the limitations of the applied hint generation algorithm. (The unwrapping hint has influence when there's an ambiguity regarding how to create a Java object form an FTL value. In the vast majority of the cases, a too generic hint has no effect.)

The limitation of the applied algorithm is that, a single common unwrapping hint class is chosen for a given argument position shared by the overloads that has the same number of parameters. The issue with the too generic hints had several instances:

(a) When the most specific common class/interface of two same-position parameter types were searched, if there was multiple common class/interfaces that had no relationship (this is always at most one class and one or more unrelated interfaces), due to the ambiguity it has felt back to using Object as the unwrapping hint. Now if there's a non-Object class among them in such case, it will be chosen as the hint. Otherwise if only a single interface remains by removing Cloneable, Serializable, and Comparable (in that order), that will be chosen. Only then it falls back to Object.

(b) The common most specific class of a primitive type and the corresponding wrapper class was sometimes Object instead of the wrapper class. This depended on Java's the internal ordering of the methods, and so were quite unpredictable.

(c) The common superclass of a numerical primitive value and a numerical non-primitive value was always Object, now if the are primitive-boxing class pair, then it's the boxing class, otherwise it's Number.

(d) If the varags parameter position was not the same in all the overloaded varargs methods, sometimes some varargs arguments where unwrapped with too generic hints. When this happened was unpredictable as it depended on the internal method ordering.)