P4
1. Spec for methods, which accept DELETE_ON_CLOSE option should indicate that checkDelete method is invoked, if this option is specified. Currently Files.newBufferedWriter lacks this specification.
2. On Solaris/Linux if DELETE_ON_CLOSE is specified, the appropriate file is unlinked from the directory when opened and therefore appears inaccessible via path. Files.exists(path) method returns false and an attempt to open such a file using another stream/channel fails with IOE. So it is platform-dependent if the file opened in that mode is accessible from outside opening stream/channel. That fact should be clearly specified.
3. Due to (2) DELETE_ON_CLOSE option appears useless for Files.newBufferedWriter and Files.newOutputStream - in that mode these outputs act like /dev/null, because we cannot read what we've just written. That fact is worthy to be mentioned in the spec.
2. On Solaris/Linux if DELETE_ON_CLOSE is specified, the appropriate file is unlinked from the directory when opened and therefore appears inaccessible via path. Files.exists(path) method returns false and an attempt to open such a file using another stream/channel fails with IOE. So it is platform-dependent if the file opened in that mode is accessible from outside opening stream/channel. That fact should be clearly specified.
3. Due to (2) DELETE_ON_CLOSE option appears useless for Files.newBufferedWriter and Files.newOutputStream - in that mode these outputs act like /dev/null, because we cannot read what we've just written. That fact is worthy to be mentioned in the spec.