Hi Brent,
I am not an expert here, and I am hoping someone from I18N
also reviews this.
A nit
- " LC_ALL" + LC_ALL + "\n" +
+ " LC_ALL=" + LC_ALL + "\n" +
If Mac is the only system affected by this, should we make the checks for
LC* and LANG specific to Macs since other platforms don't have this issue ?
I am concerned this might pass vacuously on systems configured correctly.
Since the test extends TestHelper all you have to do is:
- if("C".equals(LANG) || "C".equals(LC_ALL)) {
+ if (isMacOSX && ("C".equals(LANG) || "C".equals(LC_ALL))) {
Kumar
Hi,
This test started failing after 8003228 [1] was putback (setting
sun.jnu.encoding to UTF-8 on Mac). It tests if java is able to launch
a .jar stored in a directory named with two-byte characters.
The code comments in the test case state that (on Unix) it expects
LC_ALL to be set (to ja_JP.UTF-8/ja_JP.utf8/ja_JP.ujis), though it
also seems to work with en_US.UTF-8).
Our automated build+test Macs have LANG=C, so the test has been
"passing" without actually testing the functionality.
The test case determines if the environment is suitable for testing by
checking if sun.jnu.encoding is either "MS932" or "UTF-8" (on Mac,
this is now always UTF-8). The test doesn't actually check LC_ALL.
I think the test should also check the LANG & LC_ALL env vars, and go
back to "fake passing" the test if either is set to 'C'. This would
allow the test to continue to run "for real" in the default Mac
environment (LANG=en_US.UTF-8), and stop the test from failing on the
build+test Macs.
Of course it would be even better to update the test so the automated
test machines actually test the intended functionality. On UNIX at
least, perhaps it could find something suitable to set LC_ALL to
before attempting to launch the .jar. I can file a separate bug for
this.
Webrev is here:
http://cr.openjdk.java.net/~bchristi/8006039/webrev.00/
Thanks,
-Brent
[1]
http://bugs.sun.com/view_bug.do?bug_id=8003228
