Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Trivial 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
        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
        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
        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
        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
        Dawid Weiss added a comment -

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

        Show
        Dawid Weiss added a comment - Follow-up discussion wrt overriding file.encoding: http://markmail.org/message/q4eeac7q6fjalbtd
        Hide
        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
        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
        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
        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
        Hoss Man added a comment -

        hoss20120711-manual-post-40alpha-change

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

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development