Uploaded image for project: 'JBRULES'
  2. JBRULES-2853

ResourceFactory.newClassPathResource(drlPath) behaves differently on different platforms (linux, windows): it parses the file with different encodings


    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 5.4.0.Final
    • Component/s: None
    • Labels:


      This really sucks for non English people English people write in pure ASCII, so they don't suffer from this problem.
      French, Dutch etc mix in Latin-1 chars. Russian, Chinese use something else.

      The root problem: There are 2 ways to create an InputStream:

      • with encoding = GOOD, use encoding "UTF-8" and there are no problems.
      • without encoding: use the default platform encoding = BAD
        • Linux: UTF-8, Windows in Belgium: Latin-1, Windows in China: Chinese-1, Windows in Sweden: Latin-2, ...
        • Java's InputStream should have just defaulted it on UTF-8

      Proposition 1: Overloaded method which has an extra String encoding:

      • ResourceFactory.newClassPathResource(drlPath, encoding)
      • similar tactic as InputStream

      Proposition 2: Keep it simple. We decide what a DRL file is.
      Just like an XML file says to hell with the specified encoding, so can we.
      Note: All XML files default to UTF-8 encoding, and you can overwrite it in a header in the XML file itself (= self-describing): no need to mess around in the java code.
      Same principle: All DRL files are default UTF-8 encoding. Optionally we can define an encoding header later.

      I strongly prefer proposition 2. The world has got enough encoding problems.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  ge0ffrey Geoffrey De Smet
                  ge0ffrey Geoffrey De Smet
                • Votes:
                  1 Vote for this issue
                  2 Start watching this issue


                  • Created: