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

[Gerard Krupa (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449754#comment-13449754 ] 

Gerard Krupa commented on DROOLS-1703:
--------------------------------------

There is something odd I'm seeing, where this fails randomly on our CI box because the constructors appear to be enumerated in a random order each time and doesn't fail on developer PCs because they seem to be enumerated in declaration order.  The CI box is an 8-core EC2 instance running CentOS 7 and the dev machines are dual core i7s running Ubuntu 16.04.  They are running identical versions of OpenJDK and Maven.

> 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.



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