Apache commons-lang has two overloaded BooleanUtils.and
methods.
public static boolean and(final boolean... array) {
public static Boolean and(final Boolean... array) {
When calling BooleanUtils.and
method, ambiguous method call error is thrown.
java: reference to and is ambiguous
both method and(boolean...) in org.apache.commons.lang3.BooleanUtils and method and(java.lang.Boolean...) in org.apache.commons.lang3.BooleanUtils match
It can be called using following syntax.
BooleanUtils.and(new Boolean[]{Boolean.TRUE, Boolean.TRUE});
But, as per the method's javadoc, the usage detail is different.
public class BooleanUtils extends Object. Operations on boolean primitives and Boolean objects. This class tries to handle null input gracefully. An exception will not be thrown for a null input. Each method documents its behavior in more detail.
The isTrue static method of the BooleanUtils class can be used to check if the passed Boolean value is equal to true .
This is because overloading a varargs method doesn't work for the primitive type and its object wrapper type. Its nothing to blame about the apache-commons-lang3.
During the compile time varags method signatures are replaces as Array
. Here the BooleanUtils.and
methods will convert as
public static boolean and(final boolean[] array) { ...
}
public static boolean and(final boolean[] array) { ...
}
And the parameters you pass to them get replaced to an Array
. In this case you will get this
BooleanUtils.and(new boolean[]{true, true})
BooleanUtils.and(new Boolean[]{Boolean.TRUE, Boolean.TRUE})
You can find that the your converted method parameter is an Array
type and it matches the both methods against this type. So compiler finds neither one is more appropriate than the other one by itself. It can't decide which method is the most-specific to call.
But when you yourself declare BooleanUtils.and(new Boolean[]{Boolean.TRUE, Boolean.TRUE})
or BooleanUtils.and(new boolean[]{true, true})
that exposes your intention to compiler and method is chosen without boxing or autoboxing.
And this is how compiler identify applicable methods n 3 phases. See details about Choosing the Most Specific Method
The first phase (§15.12.2.2) performs overload resolution without permitting boxing or unboxing conversion, or the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the second phase.
The second phase (§15.12.2.3) performs overload resolution while allowing boxing and unboxing, but still precludes the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the third phase.
The third phase (§15.12.2.4) allows overloading to be combined with variable arity methods, boxing, and unboxing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With