Fwd: Re: JTReg tests results on other ports

[Alan Bateman]

Henri Gomez wrote:
> I upload to openjdk-osx-build site todays jtreg reports with latests
> settings in jtreg calls.
>
> http://openjdk-osx-build.googlecode.com/files/test-java-lang-results-20110929.tar.gz
> http://openjdk-osx-build.googlecode.com/files/test-langtools-results-20110929.tar.gz
>
> Inside you'll find JTwork and JTreports for each run :
>
> jtreg -jdk:MY_JDK_PATH -agentvm -ignore:quiet -v:summary test/java/lang
> jtreg -jdk:MY_JDK_PATH -agentvm -ignore:quiet -v:summary test/tools
>
> It should be simpler for you to localize OS/X specific problems (ie:
> javac path build error)
>
> Cheers
>   
I grabbed test-java-lang-results-20110929.tar.gz and briefly look at the 
24 failures you are seeing. Looks like 20 of them are because jtreg 
can't find JUnit and I see you are discussing that with Jon. One thing 
to point out is that 19 of these JUnit tests do not exist upstream so as 
per another thread here, we need to make sure these tests are stable and 
working on other platforms before they are pushed upstream. The 
remaining one (invoke/InvokeDynamicPrintArgs.java) is jdk7's ProblemList 
because of the JUnit dependency.

The remaining 4 failures seem to be test porting issues:

OperatingSystemMXBean/TestSystemLoadAvg.sh runs "uptime" and parses the 
output but the format is different on MacOSX compared to Solaris and Linux.

ProcessBuilder/Zombies.java assumes that /bin/true exists on non Windows 
operating systems but it doesn't seem to be present on MacOSX.

ClassLoader/deadlock/TestCrossDelegate.sh needs to set FS when running 
on BSD or MacOSX as otherwise it can't construct the path to javac (at 
least I assume this is why it ends up trying to use Homebinjavac instead 
of Home/bin/javac.

ProcessBuilder/Basic.java isn't immediately obvious but I think the test 
is finding __CF_USER_TEXT_ENCODING in the environment of a process that 
is creates with only LC_ALL set in the environment.

Hopefully this helps. I see in one of your mails that you listed several 
java.lang.instrument tests. I don't seem them here but one thing to 
mention is that many of the instrument tests are shell tests as they 
construct agent JAR files and it's likely these shell tests will need to 
be changed to work on MacOSX if they haven't been done already. As an 
aside, we probably should take a pass over all the shell tests in the 
repository and fix them to avoid needing to modify them for every 
platform. I realize this isn't possible with every one of them but for 
many of them they could assume Unix path and file separators when not 
running on Windows.

-Alan.