#35 Subtle bug in BSF-subfunction invokeStrict

[Rony G. Flatscher]

Method resolution in BSF4ooRexx is done automatically by choosing one with paramater types to which the Rexx supplied values can be converted to.

There is currently a subtle bug: if there are multiple methods with the same name available then combinations of parameter and argument types may occur which cause the wrong method to be selected and executed, which is then a problem, when the operations implemented in those methods are semantically different.

An example is the java.util.List method named "remove" which is defined with the following signatures:

• public abstract boolean java.util.List.remove(java.lang.Object)
• public abstract java.lang.Object java.util.List.remove(int)

Currently, even if using the BSF-subfunction "invokestrict", where each argument has a type indicator (a string) immediately before itself [e.g. list~bsf.invokeStrict("remove", "int", index)], currently may pick the wrong remove method, ie. the one with "remove(java.lang.Object)".

[Rony G. Flatscher]

Fixed in [r401].