Consider replacing `FileOutputStream` with `Files.newOutputStream`

[ppkarwasz]

Since Java 7 two methods are available to open new files:

• FileOutputStream#new,
• Files#newOutputStream.

While they mostly perform the same OS operations, there is a significant difference between the two on Windows: the IO method opens the file without the FILE_SHARE_DELETE option, whereas the NIO method adds the FILE_SHARE_DELETE option (cf. this SO question).

Since log files on UNIX can already be deleted without stopping the application, this change would allow an alignment between the behavior of Log4j on Windows and UNIX.

I discussed this with @garydgregory on Slack.

[vy]

There are more (platform-independent!) hazards surrounding FileOutputStream::new. Please indeed replace them with Files::newOutputStream.

[jvz]

I like this idea because it also supports use of other file system implementations based on what the user has installed. That could also be useful in tests if we used something like https://github.com/google/jimfs for in-memory file system testing.

[ppkarwasz]

A little note on the implementation of this task: as I learned in #2921, to properly convert a String to a Path, we need to use code like this:

Path path;
URI uri = NetUtils.toURI(uri);
if (uri.isAbsolute()) {
    path = Paths.get(uri);
} else {
    path = Paths.get(uri.getPath());
}

This will ensure that we can also handle Paths that are not on the default FileSystem (Paths.get(String) only searches the default FS).

[ppkarwasz]

This is related to #2537.