Adding Path-based constructors to various classes
kasperni at gmail.com
Tue Dec 18 15:49:01 UTC 2018
I don't know if it makes sense at this time. But if File and Path had both
We could just accept a CharSequence for every method that needs a
path/file. Allowing to parse along either a File, Path or String.
I've have done myself in some APIs that uses tree-based structures. Where I
had a generic TreePath interface extending CharSequence.
And then every method operating on a path would just receive a CharSequence
path. Accepting both Strings and Treepaths.
On Tue, 18 Dec 2018 at 01:47, Brian Burkhalter <brian.burkhalter at oracle.com>
> (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.
> > On Dec 17, 2018, at 4:12 PM, Andrew Luo <
> 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