Adding Path-based constructors to various classes

[Kasper Nielsen]

Hi,

I don't know if it makes sense at this time. But if File and Path had both
implemented CharSequence.
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.

/Kasper

On Tue, 18 Dec 2018 at 01:47, Brian Burkhalter <brian.burkhalter at oracle.com>
wrote:

> (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 <
> 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?
>
>