Adding Path-based constructors to various classes
andrewluotechnologies at outlook.com
Tue Dec 18 00:56:59 UTC 2018
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.
From: Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: Monday, December 17, 2018 4:47 PM
To: Andrew Luo <andrewluotechnologies at outlook.com>; nio-dev <nio-dev at openjdk.java.net>
Cc: Core-Libs-Dev <core-libs-dev at openjdk.java.net>
Subject: Re: Adding Path-based constructors to various classes
(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<mailto:andrewluotechnologies at outlook.com>> wrote:
Many classes such as:
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