This appears to be a problem when combining Kogito codegen on a non-UTF8-for-the-system's-default-OS, such as Windows.

Kogito codegen relies on KIE Resource(s), and to be compatible with GraalVM NI, a Reader is always instantiated by creating an InputStreamReader without specifying the character encoding, thus relying on the JDK default behaviour --that is: use the OS' default encoding unless otherwise specified.

An override to this default behaviour could be specified to the JDK with the -Dfile.encoding=

This problem is even more exacerbated by using the Reader with XStream, as Drools DMN engine uses XStream for xml processing, and according to the XStream FAQ would only rely purely on the Reader's encoding.

To recap: a text based file (.dmn) is always persisted in UTF-8 (by the DMN Editor), but the InputStreamReader is created by kogito codegen by relying on the JDK's behaviour.

Solution.

What I could do here, is that:

• if an xml prolog for UTF-8 is maintained in the file,
• or I detect "xmlns:kie="http://www.drools.org/kie/dmn" to be searched as a magic-string in the actual content

I set the Reader's encoding to UTF-8 programmatically.