Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass

[Alexey Varlamov <al...@gmail.com>]

27.10.06, Salikh Zakirov<Sa...@intel.com> написал(а):
> 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?
>
I suppose the intention was to test generics parser's ability to work
with supplementary unicode characters, and the most straightforward
way is to let Java compiler compose signatures from given types, with
class files created as a side effect. Probably such tests should be
unit tests of the parser itself, with hardcoded string parameters to
avoid extra dependency on environment. At least until VM is
unicode-ready or there is a bunch of unicode tests for the whole
stack...