Issue Report: Runtime ClassCastException with accumulate max() on BigDecimal - Should Fail at Compile Time

[Geeta Dhamak]

## Issue Report: Runtime ClassCastException with `accumulate max()` on BigDecimal - Should Fail at Compile Time

**Drools Version:** 10.0.0  
**JDK Version:** Java 21

### Problem Description

When using `accumulate` with `max()` function on a `BigDecimal` field, if the result binding type is incorrectly declared as `Double()`, the rule **compiles successfully** but **fails at runtime** with a `ClassCastException`.

### Expected Behavior
The rule compilation should fail with a type mismatch error, preventing runtime exceptions.

### Actual Behavior
- ✅ Rule compiles without errors
- ❌ Runtime failure: `java.lang.ClassCastException: class java.math.BigDecimal cannot be cast to class java.lang.Double`

### Reproducible Example : attached in discussion
Java class: TestRule.java

Sample drl : mySample.txt

Sample dom : Item.java
error logs : errorLog.txt

**Runtime Error:**
```
java.lang.ClassCastException: class java.math.BigDecimal cannot be cast to class java.lang.Double
```

### Root Cause
The `max()` accumulate function returns the same type as the input field (`BigDecimal`), but the binding declares `Double()`. The compiler does not catch this type mismatch.

### Workaround
Change the binding type to match the actual return type:
```drl
$maxSeq: BigDecimal()  // Correct
// OR
$maxSeq: Number()      // Also works (parent type)
```

### Question
Should the Drools compiler detect this type mismatch and fail at compile time rather than allowing a runtime exception? This would improve type safety and developer experience.

[Geeta Dhamak]

Could you please share some update on my above query.

[Toshiya Kobayashi]

Hi,

I have reproduced the issue with 10.0.0, and confirmed that it's fixed in 10.1.0.

It's because of https://github.com/apache/incubator-kie-drools/commit/c4711a9bda44e926104c3801ad87492753ed9ecd . It was not intended to fix your exact issue, but fixed it as an extra benefit. Please try.

Toshiya

2025年12月17日水曜日 17:54:30 UTC+9 geeta...@gmail.com:

[Geeta Dhamak]

Hi, 
Earlier issue with ClassCast is now fixed in drool 10.1.0. Thanks for this quick fix.

I wanted to raise a concern regarding rule compilation behavior in Drools, specifically around variable binding and constraint evaluation.

We observed a scenario where a rule compiles successfully but produces incorrect runtime behavior due to missing $ in variable bindings. Ideally, such cases should fail during compilation rather than silently executing with unintended logic.

Example

Before (compiles but behaves incorrectly):

rule "SampleRule"
when
 temp : TempObject(fieldA == "X", fieldB : fieldB)
 AnotherObject(fieldA == fieldA)
then
 temp.setFlag("Y");
end

In this case:

• fieldA == fieldA becomes a self-comparison, always true

• The rule fires incorrectly for all facts

---

After correction (expected behavior):

rule "SampleRule"
when
 $temp : TempObject(fieldA == "X", $fieldB : fieldB)
 AnotherObject(fieldA == $fieldB)
then
 $temp.setFlag("Y");
end

Here:

• $fieldB is properly bound and used

• Constraint behaves as intended

---

Concern

The issue is that the incorrect version:

• Compiles without any warning or error

• Leads to logically incorrect rule execution

• Is difficult to detect, especially in large rule bases

---

Question / Suggestion

Is there any existing mechanism (or roadmap plan) in Drools to:

1. Detect self-comparisons like:

   fieldA == fieldA

2. Validate usage of bound variables vs unbound fields

3. Provide compile-time warnings or strict mode for such cases

Even a warning-level validation would significantly help prevent subtle production issues.

---

Why this matters

In large-scale rule systems, especially during migrations or automated transformations, such issues are hard to catch and can lead to incorrect business outcomes without obvious failures.

---

Appreciate your guidance on whether such validation exists or if there are recommended best practices/tools to detect these cases.

Thanks,
Geeta.

[Alex Porcelli]

Thank you for reporting the issue. I've created a tracker for it here:

https://github.com/apache/incubator-kie-issues/issues/2272

And submitted a PR with a proposal:

https://github.com/apache/incubator-kie-drools/pull/6618

-

Alex

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/drools-usage/e718ba54-d61a-46fd-a42d-431cca857551n%40googlegroups.com.