When incompatible 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: CentOS 7 (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. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. https://github.com/GJKrupa/DROOLS-1703