RFR: 8048020 - Regression on java.util.logging.FileHandler (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Wed Jun 25 15:38:29 UTC 2014

On 25/06/2014 16:21, Daniel Fuchs wrote:

On 6/25/14 5:07 PM, Alan Bateman wrote:

Catching OverlappingFileLockException is usually a sign of a mis-use. Can you summarize how this comes about (given the locking on "locks"). A file is just a file. So nothing prevents some other piece of code in the same process to call FileChannel.lock() directly. For instance, another Handler implementation might do that - given that our 'locks' HashMap is private - it wouldn't be able to use it. Okay, so this concern isn'tFileHandler but rather malicious or misguided usages in other code running in the same VM. In that case I think the comment could be a bit clearer that it's something other than the FileHandler that is locking the file.

The issue here is that CREATE + WRITE + APPEND will probably succeed if the file exists - even though we can't write in its parent dir. I am not sure we should be concerned about the performance of opening the file for the FileHandler. It's usually not something you do very often. I don't think the Files.isXXX is useful here, especially if there are other things changing the file system at the same time. There is no guarantee that FileChannel.open will succeed. This may be a case where you have to catch the IOException and continue (it's not nice to use exceptions for control-flow but this may be one of these cases where it becomes necessary.

-Alan.

More information about the core-libs-dev mailing list