[jboss-jira] [JBoss JIRA] (DROOLS-1703) When multiple varargs constructors exist, resolution sometimes incorrect

[Gerard Krupa (JIRA)]

Gerard Krupa created DROOLS-1703:
------------------------------------

             Summary: When multiple varargs constructors exist, resolution sometimes incorrect
                 Key: DROOLS-1703
                 URL: https://issues.jboss.org/browse/DROOLS-1703
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.5.0.Final
         Environment: Ubuntu 16..0.4 (x86_64)

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
            Reporter: Gerard Krupa
            Assignee: Mario Fusco


We have a class with 3 constructors:
Thingy(String name)
Thingy(String name, Object... args)
Thingy(String name, String version, Object... args)

When calling the constructor with a single paramater from a DRL:
    Thingy(drools.getRule().getName())

we sometimes get an odd exception in our unit tests:
{{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[INFO] 	at java.lang.String.substring(String.java:1927)
[INFO] 	at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17)
[INFO] 	at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975)
[INFO] 	at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396)
[INFO] 	at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}}

The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore.  The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability.  The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type).

All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used.  This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)