Details
Bug
Closed
Major
Description
When a class has a constructor, like:
class Person {
...
Person( String name, String likes, int age )
...
}
And someone writes code like:
new Person( "bob", 123, 456 )
MVEL should raise errors, since there is no constructor with a numeric parameter on the second argument. Although, MVEL is coercing 123 into a String and calling the constructor anyway. This is a coercion that is completely unexpected and most likely the user writing that code did not intended to use that constructor.
Also, non-existing constructors only generate error at runtime, when one would expect them to generate a compile time error. For instance, writing the following will only generate a runtime error, not a compile time error:
new Person( 1, 2, 3, 4, 5, 6, 7, 8, 9 )
I added a simple test case to CoreConfidenceTests.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
I know this won't exactly be a satisfying answer, but this has always been the behaviour of MVEL. In fact, it's documented to behave this way: http://mvel.codehaus.org/MVEL+2.0+Typing
See the example from arrays. MVEL, even in strong typing mode considers the coercion of any type to String as "safe". It always has.
In cases of overloaded methods/constructors, MVEL should always choose the method or constructor which is the closest match for the types being passed in.
A good way of thinking about it, is that MVEL considers java.lang.String to be a slightly higher-order wildcard type than java.lang.Object. The reason for this is a practical one: it allows integration with MVEL, due to the type coercion system to be much easier in many case, by not requiring the integrator to finesse ingress types.