Adding Path-based constructors to various classes
brian.burkhalter at oracle.com
Tue Dec 18 00:47:17 UTC 2018
(looping in nio-dev)
The NIO APIs (Java 1.4) were intended to supplement the pre-existing Java I/O APIs and this effort was continued in the NIO.2 APIs (Java 7). The Path interface is part of the latter. My impression is that the intent was more to supersede the older APIs than to enhance them to coexist better with the new ones. The addition for example of the constructors you suggest therefore would not be encouraged despite the convenience they might afford in some situations. There are others on these mailing lists however who know the historical context of this area better than I do and who I expect will chime in with a better answer.
> On Dec 17, 2018, at 4:12 PM, Andrew Luo <andrewluotechnologies at outlook.com> wrote:
> Many classes such as:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/ZipFile.html>
> have constructors that use the File API or String but no constructor that takes Path. Is there any interest in adding these? The reason I ask this is because we now encourage new code to use Path instead of File, so having to do .toFile() in many places can seems unnecessary. Then again, this is a minor annoyance, but I think it is a useful addition. What do you guys think?
More information about the core-libs-dev