Fwd: Code Review 7073295: TEST_BUG: test/java/lang/instrument/ManifestTest.sh causing havoc (win)

[Daniel D. Daugherty]

Thanks for closing the loop. The changes are good as is.

Dan


On 8/9/11 2:02 PM, Chris Hegarty wrote:
> On 08/ 9/11 05:11 PM, Daniel D. Daugherty wrote:
>> On 8/9/11 8:29 AM, Chris Hegarty wrote:
>>> Sorry, should have cc'ed serviceability-dev at openjdk.java.net too.
>>>
>>> -Chris.
>>>
>>> -------- Original Message --------
>>> Subject: Code Review 7073295: TEST_BUG:
>>> test/java/lang/instrument/ManifestTest.sh causing havoc (win)
>>> Date: Tue, 09 Aug 2011 14:05:08 +0100
>>> From: Chris Hegarty <chris.hegarty at oracle.com>
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>,
>>> "alan.bateman at oracle.com" <alan.bateman at oracle.com>
>>>
>>> Hi,
>>>
>>> This test creates temporary directories in the scratch area with spaces
>>> in their names. It fails on Cygwin because jtreg cannot cleanup after
>>> it. Easiest to just have the test cleanup (minimally) after itself.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~chegar/7073295/webrev.00/webrev/
>>>
>>> Thanks,
>>> -Chris.
>>
>> I run these tests all the time on WinXP/Cygwin so the use of the
>> '-samevm' option is the enabler here also. 'samevm' mode is mentioned
>> in this bug report (yeah!), but it could be more clear that the test
>> falls over because that option is used.
>
> Sorry my fault, most of our recent test issues have been caused by 
> samevm mode, it's hard to think of anything else now ;-(
>
>> Alan and I discussed this test off list and our last hypothesis was
>> that the strange filenames/dirnames were the culprit. I just didn't
>> get back to the issue. Sorry about that.
>>
>> I'm not quite sure I have my brain wrapped around why
>> ExampleForBootClassPath had to be added to the "@run build" line,
>> but I'm OK with that change also.
>
> The reason for adding ExampleForBootClassPath to the build line is 
> that the shell script at some point moves 
> ExampleForBootClassPath.class to a different dir.  If the test is 
> rerun without removing ManifestTestApp.class, then jtreg does not 
> recompile ManifestTestApp.java, which means that 
> ExampleForBootClassPath doesn't get compiled, which means the .class 
> file is not in the expected dir. (Thanks JimH for finding this.)
>
> Not a showstopper, but worth fixing since we noticed it.
>
>> I'm presuming that you are only cleaning up the hard to remove stuff
>> and leaving the other dirs for JTREG to clean up. For example, there
>> are two dirs: "has_leading_blank" and " has_leading_blank". The dir
>> without the blank has the bad class file in it to make sure that we
>> actually use the right dir (the one with the blank in it). Your fix
>> only removes " has_leading_blank" and "has_leading_blank" is left
>> behind.
>
> That's right, not exactly pretty but I though it was the simplest way 
> to go here. jtreg can handle the rest.
>
>> The bug ID list should also be updated, but that's a nit.
>
> Ahhh... sorry. Probably not worth filing a CR to add this, but I will 
> piggyback it to my next changeset if that is ok.
>
> -Chris.
>
>> Thumbs up.
>>
>> Dan
>>
>>
>>