Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-BETA, 6.0
    • Component/s: general/test
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Stated in the code:

          // TODO we can't randomize this yet (it drives ant crazy) but this makes tests reproduce
          // in case machines have different default charsets...
          sb.append(" -Dargs=\"-Dfile.encoding=" + System.getProperty("file.encoding") + "\"");
      

      But this should work without any problems with junit4 because communication streams are separate and we're decoding output properly (or so I hope).

      Try and see what happens

        Activity

        Hide
        rcmuir Robert Muir added a comment -

        This would be really nice. The limitation before, if i remember right, was in ant-junit, because
        by changing the default charset of the forked jvm, it would also change the encoding of the output from the test runner:
        this caused it to go crazy.

        It would be nice if junit4 could somehow separate these two concerns: if this could somehow work, imagine how tests running with
        a default charset like UTF-16LE would actually fail when they rely upon the system charset and shouldnt, even if they use all
        ascii in their tests like they usually do.

        Show
        rcmuir Robert Muir added a comment - This would be really nice. The limitation before, if i remember right, was in ant-junit, because by changing the default charset of the forked jvm, it would also change the encoding of the output from the test runner: this caused it to go crazy. It would be nice if junit4 could somehow separate these two concerns: if this could somehow work, imagine how tests running with a default charset like UTF-16LE would actually fail when they rely upon the system charset and shouldnt, even if they use all ascii in their tests like they usually do.
        Hide
        dweiss Dawid Weiss added a comment -

        junit4 is already default encoding independent (it uses its own communication channel). I haven't tested this intensively though so I'll give it a shot locally first and them if everything works well, switch the testing framework to randomize file.encoding.

        Show
        dweiss Dawid Weiss added a comment - junit4 is already default encoding independent (it uses its own communication channel). I haven't tested this intensively though so I'll give it a shot locally first and them if everything works well, switch the testing framework to randomize file.encoding.
        Hide
        dweiss Dawid Weiss added a comment -

        Follow-up discussion wrt overriding file.encoding:
        http://markmail.org/message/q4eeac7q6fjalbtd

        Show
        dweiss Dawid Weiss added a comment - Follow-up discussion wrt overriding file.encoding: http://markmail.org/message/q4eeac7q6fjalbtd
        Hide
        rcmuir Robert Muir added a comment -

        I totally disagree with everything the jdk developers are saying. They tend to just whine when we find bugs in their shit.

        we should continue to do this: its important to seek out these default charset bugs (this is because of their stupid design).

        Show
        rcmuir Robert Muir added a comment - I totally disagree with everything the jdk developers are saying. They tend to just whine when we find bugs in their shit. we should continue to do this: its important to seek out these default charset bugs (this is because of their stupid design).
        Hide
        dweiss Dawid Weiss added a comment -

        I understand their argument ("combination not encountered in practice") but I disagree with the claim it should justify crappy code. The default charset should be independent of the OS-filesystem interaction. It should just work with UTF-16.

        Anyway, when I run our stuff with enforced UTF-16 lots of weird things start to happen. new FileReader(file), benchmarks run forever (will provide a seed) and such. I'll commit in one by one and then we can start testing/ fixing locally.

        Show
        dweiss Dawid Weiss added a comment - I understand their argument ("combination not encountered in practice") but I disagree with the claim it should justify crappy code. The default charset should be independent of the OS-filesystem interaction. It should just work with UTF-16. Anyway, when I run our stuff with enforced UTF-16 lots of weird things start to happen. new FileReader(file), benchmarks run forever (will provide a seed) and such. I'll commit in one by one and then we can start testing/ fixing locally.
        Hide
        hossman Hoss Man added a comment -

        hoss20120711-manual-post-40alpha-change

        Show
        hossman Hoss Man added a comment - hoss20120711-manual-post-40alpha-change

          People

          • Assignee:
            dweiss Dawid Weiss
            Reporter:
            dweiss Dawid Weiss
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development