Gregory Shimansky wrote: >> But on Linux these tests fail with >> lost of different exceptions: >> >> For java.lang.ClassGenericsTest: >> >> java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z >> java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z >> java.lang.TypeNotPresentException: Type >> java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present >> >> For java.lang.ClassGenericsTest4: >> >> Some NPEs from unobvious sources. I've attached two test reports to >> this email. Anyways, it looks like timeout is not the case for these >> tests failures. > > Ok I think I've found the cause of problems with these two tests on > Linux which I had yesterday. On Gentoo I have russian locale set > "ru_RU.KOI8-R" while on all other Linux installations it appears there > are various combinations of *.UTF-8 locales (usually "en_US.UTF-8", but > I found "en_AU.UTF-8" on oner server). > > I experimented a bit with this stuff and found out that these tests work > ok when locale is some sort of UTF-8 one, including ru_RU.UTF-8 one. > > The result of test run is actually affected by locale set at compilation > time, not the one set at the subsequent test runs. When locale at > compile time is set to *.UTF-8, then test run is successful on any > locale set after it. If locale is set to something simple like "C" (!) > or "ru_RU.KOI8-R" at compile time then test run fails no matter what > locale is set when tests are running. > > I wonder what we should blame here, compiler, VM, classlib or the tests?
IMHO, the test is not correct for non-unicode configurations, as some unicode-named classfiles cannot be saved with filename in locale-specified character set. I think that fixing \uXXXX characters in these tests to some ASCII characters should fix the problem (I haven't checked myself). However, I do not know the original intention why those characters were put to the class names in the first place, does anyone know an explanation?
