Byteman employs the notion of a Numeric type i.e. one whose which passes the isNumeric() test. That embraces means primitives, instances of the corresponding box types like java.lang.Integer, java.lang.Float etc and also the common super to all the box types java.lang.Numeric.

When a comparison operation compares a Numeric expression with another Numeric expression the type checker allow for whatever numeric interconversion is necessary and derive a suitable comparison type to which both expressions are converted before comparison. This allows all 6 forms of comparison (EQ, NE, GT, GE, LT, LE) to work correctly.

However, it also makes sense to compare a Numeric against a non-Numeric for either equality or inequality (EQ or NE) even though an ordered comparison makes no sense. More precisely, the case where one of the expressions is of type Object leaves open the possibility that it will actually evaluate to an instance of one of the box types and therefore be compared to the other expression, possibly after boxing.the latter if it is primitive. Of course, in the case where the non-Numeirc expression is some non-Numeric subtype of Object then the comparison is bound to fail but that does not invalidate the benefit of providing the comparison for the general case.

Unfortunately, the current type checker rejects all Numeric to non-Numeric comparisons as an invalid numeric comparison. This should be corrected.