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
Mon Feb 25 22:00:48 UTC 2013

I can take care of it.

Kumar

Thanks for the review, guys.

Think I've got it all in: http://cr.openjdk.java.net/~bchristi/8006039/webrev.02/ For the Copyright, do I just need to change the year(s) to "2012, 2013,"? Also, thanks a lot for running the Windows testing, Kumar.

Can someone push this for me? I can send a patch (or bundle) file... Thanks, -Brent On 2/25/13 11:09 AM, Kumar Srinivasan wrote: couple of minor nits I did not see in rev 01. Copyright,

- if("C".equals(LCALL) || "C".equals(LANG)) { + if ("C".equals(LCALL) || "C".equals(LANG)) { Kumar

Looks good. Thank you for fixing this. Naoto On 2/25/13 10:53 AM, Brent Christian wrote: On 2/22/13 10:22 AM, Naoto Sato wrote: check not only "C" but also other locales that do not use UTF-8 encoding.

I would like to make the test more robust (per 8008761), though my focus at the moment is to avoid a test failure on our automated test systems, which all use "C". I've made a note in 8008761 that we should check for other locales that do not use UTF-8. > Also, "LCALL" precedes "LANG" environment variable, so I'd check "LCALL" first, and if it is not exported then check "LANG" variable. Good point - I'll check LCALL first. Updated webrev with re-ordered LCALL check (and "LCALL=" output change) is here: http://cr.openjdk.java.net/~bchristi/8006039/webrev.01/ Thanks, -Brent

On 2/21/13 4:34 PM, Brent Christian wrote: 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