RFR: 8006039 : test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C (original) (raw)

Kumar Srinivasan kumar.x.srinivasan at oracle.com
Fri Feb 22 03:33:39 UTC 2013

Hi Brent,

I am not an expert here, and I am hoping someone from I18N also reviews this.

A nit

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:

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 LCALL to be set (to jaJP.UTF-8/jaJP.utf8/jaJP.ujis), though it also seems to work with enUS.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 LCALL. I think the test should also check the LANG & LCALL 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=enUS.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 LCALL 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/viewbug.do?bugid=8003228

More information about the core-libs-dev mailing list