PlusExpression must not assume operands are actually String even if its type is String

In certain legtiimate uses of the + operator to concatenate Strings the Byteman interpreter is failing with a class cast error. This only happens when an argument to the String + operation is an Object which needs converting to a String.

When the first argument of a + operation appearing in a Byteman rule is a String literal (e.g. "Dispatched at " + $1.getDate() ) the parser creates StringPlusExpresson. The interpret method of StringPlusExpresson is careful to convert whatever value its second argument evaluates to into a String by calling toString(). This is needed because the argument may be an Object (lie a date) or a numeric expression which needs coercing to a String. Byteman is expected to do this String coercion automatically without the need for the rule programmer to insert a call to toString().

When the first argument to a + operation is not a String literal (e.g. Thread.currentThread().getName() + " dispatched at ") then the parser creates a PlusExpression. In these cases it is determined at typecheck whether the operation is a String concat or a numeric add (the decision can only be made after the first arguments has been type checked).

Unfortunately, the interpret method of PlusExpresson evaluates it's arguments and then simply casts them to String before performing a String concatenate on the result of the casts. The first argument must evaluate to a String or else the type checker would not have deduced that the PlusExpression is a string concatenation. However, the second argument might be an object which needs coercing by calling toString() (e.g. in expression (Thread.currentThread().getName() + " dispatched at " + $1.getDate() the 2nd argument to the 2nd plus is a Date ). Castign to String leads to a cast exception. A call to toString() should be used instead.