[
https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi...
]
Toshiya Kobayashi updated DROOLS-2814:
--------------------------------------
Description:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses
valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as
well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of
usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses
valueOf(long val) if the parameter is int. (considering "direct supertype"
https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
was:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses
valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as
well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of
usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses
valueOf(long val) if the parameter is int. (e.g. considering "direct supertype"
https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
MVEL uses random parameter type methods for BigDecimal.valueOf(100)
-------------------------------------------------------------------
Key: DROOLS-2814
URL:
https://issues.jboss.org/browse/DROOLS-2814
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.9.0.Final
Environment: - MVEL2 2.4.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
Labels: support
Attachments: BigDecimalMvelTest.zip
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses
valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as
well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of
usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses
valueOf(long val) if the parameter is int. (considering "direct supertype"
https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)