Code Review Request: 7197662: (prefs) java/util/prefs/ fails by timeout or by "couldn't get file lock"

Kurchi Hazra kurchi.subhra.hazra at
Fri Sep 21 18:49:02 UTC 2012

On 21.09.2012 02:03, Chris Hegarty wrote:
> On 21/09/12 01:12, Dan Xu wrote:
>> Kurchi,
>> Can you append bug number 7197662 to @bug field in each test so that it
>> is easy to check its history?
> Yes, this is always a good idea.
Sure, I missed adding the bug id.
>> For your changes, I wonder why you choose to run these tests in othervm
>> mode. Thanks!
> The tests need to run in othervm mode as they are now setting a system 
> property. We don't want this system property to inadvertently effect 
> other tests, if a batch are being run in samevm or agentvm.
Right, I looked at some examples in jdk/src/test of tests which set 
system properties, and this is what they were doing. also hints toward the same.

> Assuming that '.' means the scratch directory when jtreg is running, 
> then I'm fine with these changes.

That is a good question, and while I assumed it will, the Mac code is 
clearly doing other things. I am afraid I need to investigate this
for all platforms and see what others do, and whether we need to make 
additional changes in the Mac source code to correct its
behavior. I will get back with a newer webrev soon.

- Kurchi

> -Chris.
>> -Dan
>> On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote:
>>> Hi,
>>> The tests in java/util/prefs creates new nodes under the user's home
>>> directory.
>>> This causes the tests to start out with pre-existing preferences and
>>> sometimes
>>> leads to interference between the tests. This fix is to change the
>>> userRoot
>>> property for each of these tests so these tests create nodes only
>>> under the
>>> current directory.
>>> Bug:
>>> Webrev:
>>> Thanks,
>>>  - Kurchi


More information about the core-libs-dev mailing list