[ https://issues.jboss.org/browse/DROOLS-552?page=com.atlassian.jira.plugin... ] Toshiya Kobayashi commented on DROOLS-552: ------------------------------------------ Hi Mario, I have found why those tests fail with -Dfile.encoding=MS932. DrlParser.parse() uses resource.getInputStream() + resource.getEncoding() instead of resource.getReader() which commit#c3a90d5 fixed. resource.getEncoding() returns null and then it uses platform encoding. https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/main... If our direction is "Use UTF-8 if encoding is not specified" then, we should explicitly set "UTF-8" to 'encoding' in Resource class constructors. However, then, there is another concern. If users have Drools applications which depend on platform encoding (= expecting resources are decoded with platform encoding other than UTF-8), they will face that their applications are broken. To keep backward compatibility, one idea is a system property switch. Here I introduce "drools.default.encoding.utf8.enabled" system property (by default, it's true). If it's true, default encoding would be "UTF-8". If it's false, default encoding would be platform encoding (= "file.encoding"). So if users want backward compatibility in Drools 6.2, they would need to set -Ddrools.default.encoding.utf8.enabled=false. This is the commit in my work branch. Now test cases run fine with both -Dfile.encoding=UTF-8 and MS932. Could you review and let me know your thought? This commit fixes only ClassPathResource and ByteArrayResource. To make a pull request, I would need to fix more many classes. https://github.com/tkobayas/drools/commit/162fabbe0a614dbcf9783c1e10c1aa1... -- This message was sent by Atlassian JIRA (v6.2.6#6264)