Details
-
Type:
Sub-task
-
Status: Closed
-
Priority:
Trivial
-
Resolution: Fixed
-
Affects Version/s: None
-
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
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.
Follow-up discussion wrt overriding file.encoding:
http://markmail.org/message/q4eeac7q6fjalbtd
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).
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.
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.