[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:42 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly tries to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly try to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5284:
-------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can teak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:16 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can teak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5284:
-------------------------------------------
Also CoreConfidenceTests.testNumberCoercion in mvel repo fails.
{noformat}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.118 sec <<< FAILURE! - in org.mvel2.tests.core.CoreConfidenceTests
testNumberCoercion(org.mvel2.tests.core.CoreConfidenceTests) Time elapsed: 0.087 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<7.35> but was:<7>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:283)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at org.mvel2.tests.core.CoreConfidenceTests.testNumberCoercion(CoreConfidenceTests.java:4338)
Results :
Failed tests:
CoreConfidenceTests.testNumberCoercion:4338 expected:<7.35> but was:<7>
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
{noformat}
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-5284:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Mario Fusco)
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5284:
-----------------------------------------
Summary: MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
Key: DROOLS-5284
URL: https://issues.redhat.com/browse/DROOLS-5284
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.36.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
[ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
java.lang.AssertionError: expected:<7.350000> but was:<7>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
...
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFCORE-4952) Give a better error message for standard configuration tests
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4952?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-4952:
----------------------------------
Priority: Minor (was: Major)
> Give a better error message for standard configuration tests
> ------------------------------------------------------------
>
> Key: WFCORE-4952
> URL: https://issues.redhat.com/browse/WFCORE-4952
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{StandardConfigsXMLValidationUnitTestCase}} tests validate the default configuration files. These are written into a file as a single line. This makes it a little more difficult to determine where the error is.
> A simple fix for this is to just write a new line after each line. This will give a better error message as to which line the issue is one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (WFCORE-4952) Give a better error message for standard configuration tests
by James Perkins (Jira)
James Perkins created WFCORE-4952:
-------------------------------------
Summary: Give a better error message for standard configuration tests
Key: WFCORE-4952
URL: https://issues.redhat.com/browse/WFCORE-4952
Project: WildFly Core
Issue Type: Enhancement
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
The {{StandardConfigsXMLValidationUnitTestCase}} tests validate the default configuration files. These are written into a file as a single line. This makes it a little more difficult to determine where the error is.
A simple fix for this is to just write a new line after each line. This will give a better error message as to which line the issue is one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Tracy Hires (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Tracy Hires commented on DROOLS-5280:
-------------------------------------
Yes, you're right. I see that the dmn spec in v1.3 made it clear that the FEEL that I've expected to work is not supported. I had missed both the update in the dmn spec and that the reported version of the dmn engine comforms with v1.3. (I'm not positive whether that semantic did work in earlier versions of the redhat dmn engine, but I suspect it did, as I remember finding the automatic conversion of a singleton list to a single instance to be a convenient shorthand) Thank you for taking the time to offer a complete explanation.
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years