Hi Brian, Thanks for your thoughts on this. I agree that if a class is superseded by a newer NIO.2 class with Path APIs, we should not add the Path-based APIs to the older class, but I do not believe there are NIO.2 replacements that supersede ZipFile. I also don't believe that there are any NIO.2 APIs that supersede RandomAccessFile either, but I could be wrong.
Thanks, -Andrew From: Brian Burkhalter <[email protected]> Sent: Monday, December 17, 2018 4:47 PM To: Andrew Luo <[email protected]>; nio-dev <[email protected]> Cc: Core-Libs-Dev <[email protected]> Subject: Re: Adding Path-based constructors to various classes (looping in nio-dev) Hi Andrew, 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. Thanks, Brian On Dec 17, 2018, at 4:12 PM, Andrew Luo <[email protected]<mailto:[email protected]>> 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/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?
