[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1898) \uxxxx not treated as unicode characters in literal constraint

\uxxxx not treated as unicode characters in literal constraint -------------------------------------------------------------- Key: JBRULES-1898 URL: https://jira.jboss.org/jira/browse/JBRULES-1898 Project: JBoss Drools Issue Type: Bug Security Level: Public(Everyone can see) Components: drools-compiler Affects Versions: 4.0.7 Environment: Windows XP, Reporter: Tom?? Z?lusk? Assignee: Mark Proctor I have class Fact with property value (assigned in constructor) and following rule rule when Fact(value == "K\u010d") then doSomething(); end \u010d is unicode for Czech letter ? (c with check). When I assert new Fact("K?"), this rule does not fire. When I rewrite lhs to Fact(eval(String.valueOf(value).equals("K\u010d"))), the rule fires. I debugged RETE tree and realized that the nodes are described the following way: - In the first case: - in the PackageDescription: class: LiteralRestrictionDescr toString value: [LiteralRestriction: == K\u010d] - in the RETE tree: class: LiteralConstraint toString value: restriction: [LiteralRestriction evaluator=Object == value=K\u010d] - In the second case: - in the PackageDescription: class: PredicateDescr toString value: String.valueOf(value).equals("K\u010d") - in the RETE tree: class: PredicateConstraint toString value: expression: eval( String.valueOf(value).equals("K?") ) The value is RETE tree is taken literally in the first case, so the strings are evaluated as not equal. In the second case the compiler successfully translates \uxxxx back to the original character. I think the compiler should behave the same way also in the first case. The workaround is to use predicate constraints instead of literal constraints unless it beats performance. Thank you.