What methods should go into a java.util.Objects class in JDK 7?

Ulf Zibis Ulf.Zibis at gmx.de
Mon Oct 12 16:11:06 UTC 2009


Am 12.10.2009 16:26, Alan Bateman schrieb:
> Ulf Zibis wrote:
>> Am 12.10.2009 15:03, Ulf Zibis schrieb:
>>> Additionally something like Path#unlock() would be helpful, if 
>>> copy/delete fails. For example see: 
>>> http://diamondcs.com.au/freeutilities/fileunlocker.php
>>
>> Additionally see: http://ccollomb.free.fr/unlocker/
> I assume this type of thing can lead to data loss and/or hard to 
> diagnose corruption.

Of course, such method should be used with care. The developer/user 
should first retrieve/examine some information like the blocking process 
from the locked file. But this option should be more comfortable, than 
rebooting the hole system, which too could have data loss/corruption in 
consequence.
 ... and delete always has data loss in effect. ;-)

> If you are running into sharing violations then try out the file 
> system API as the Windows provider opens files by default to allow 
> delete access (ie: close to Unix semantics by default with provider 
> specific options to control the DOS sharing mode if you really want).

In java.nio.file.Filesystem b72 I don't find information about sharing 
attributes.

> The only case where we still have a problem is memory-mapped files. 
> Changing the long standing behavior of the java.io classes is another 
> matter as that would likely break existing applications that rely on 
> the current/long standing behavior.
>
> -Alan.
>
>

-Ulf





More information about the core-libs-dev mailing list