Feature Request: Migrate Java IO to Java NIO APIs where applicable

[davidburstrom]

TL;DR

Use java.nio.file.Path and java.nio.file.Files operations instead of java.io.File wherever possible.

Benefits

• Easier to integrate in other tools, as the reliance on the real file system goes away.
• Tests can run faster as one can use https://github.com/google/jimfs to do file operations, instead of hitting the real file system.

My particular reason for this suggestion is that the ValidRelativeLinksRule is trying to resolve files outside of the analysed file. If (for particular reasons) only the analysed file is available on the real file system, the rule will raise a warning. In my case, the referenced file is available in a virtual file system, which is not readable through Java IO.

Cannot be migrated

The APIs provided by Gradle are currently centered around using Files. That is OK, since MarkdownLintPlugin simply has to call projectDir.toPath to convert into the Java NIO realm, given that everything else is migrated.

References:

• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html
• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html
• https://gquintana.github.io/2017/09/02/Java-File-vs-Path.html
• https://docs.oracle.com/javase/7/docs/api/java/io/File.html

[davidburstromspotify]

@mattmook Hi Matt! If you're interested in a PR for this, just let me know.

[davidburstromspotify]

@mattmook You can close this FR now :)

[mattmook]

Will publish this next week and close then. Planning to split out #32 at the same time

[davidburstromspotify]

Thanks! I guess Christmas got rightfully in the way :)