NIO question: Path.toFile()

[Jonathan Gibbons]

On 11/27/2014 08:47 AM, Alan Bateman wrote:
> On 27/11/2014 16:32, Jonathan Gibbons wrote:
>>
>> Alan,
>>
>> Thanks for the perspective on why it is UOE.  Kevin's blog is 
>> interesting, but as I read it, it argues against UOE :-) 
> I think there's a discussion point there as Path is an interface and 
> there are different concrete types. In any case, we can't change this 
> of course.
>
>
>> :
>>
>> I think this means that from the point of view of an API using 
>> java.nio.file.Path internally, UOE should not be propagated to 
>> clients of that API. Instead, it should be caught and rethrown as 
>> something more specific to that level of API.
>
> The toFile() method is meant for interoperability with the legacy API 
> and so some care is required to avoid using it on Paths to objects in 
> arbitrary file system that could not be represented by java.io.File. I 
> think I'd need to see more context to know if you should be 
> propagating anything or whether the issue is just an incorrect 
> assumption somewhere.
>
> -Alan

The context is that we are considering extending 
javax.tools.StandardJavaFileManager to include support for 
java.nio.file.Path as well as java.io.File.  This file manager provides 
implementations for JavaFileObject that can wrap java.io.File today, and 
java.nio.file.Path (proposed.)  An existing client will only use the 
File-centric methods, and a well-written updated client should probably 
only use the Path-centric methods, but in terms of complete API design, 
we are left with the need to specify what happens if someone starts off 
by using a method like void setLocation(Location, Iterable<Path>) and 
then later on, for some reason, tries to use Iterable<File> 
getLocation(Location). The "obvious" implementation would seem to be to 
try and use .toFile() on each element of the sequence given to 
setLocation. Which gets to the question of what to do with the UOE that 
might occur.

Yes, the potential client of this proposed updated form of 
StandardJavaFileManager may have made a mistake trying to mix and match 
File-centric methods and Path-centric methods, but that doesn't absolve 
us of the responsibility to try and "do something sensible" in this 
case. My inclination is to try and use IllegalStateException, or maybe a 
custom subtype thereof.

-- Jon