RFR: 8048020 - Regression on java.util.logging.FileHandler

Alan Bateman Alan.Bateman at oracle.com
Fri Jul 4 16:35:09 UTC 2014


On 01/07/2014 10:25, Daniel Fuchs wrote:
>
> Hi Jason, Alan,
>
> Here is an updated version of the fix that does a bounded
> retry (retries once - and if it fails, proceeds with the next
> name). I have also added NO_FOLLOW_LINKS - for the case where
> we try to open an existing Lockfile, and suppressed the
> Files.isWritable check since that will be taken care of by
> the call to FileChannel.open.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.01/
>
> I also updated the comments to make it clear that the
> file could not have been locked by another instance
> of FileHandler (since that would have been taken care
> of by our global 'locks' synchronization).
>
> best regards,
>
> -- daniel
This looks okay to me except for the zombie file case. I think I missed 
the reason for using APPEND. Also you catch FileNotFoundException (which 
is not thrown by FileChannel.open) so I wonder if you mean to catch 
IOException so that you handle all possible I/O exceptions. If you meant 
IOException to handle any error then the isWritable on the parent 
directory isn't needed (we can make the isRegularFile check go away too 
if you want).

In the test case then the the use of getAbsolutePath seems redundant. 
Also just to mention that setup method could use Files.createTempDirectory.

-Alan




More information about the core-libs-dev mailing list