7017446: (fs) Updates to file system API (3/2011)

[Wolfgang Baltes]

On 2011-03-14 07:36, Alan Bateman wrote:
>
>
> This webrev contains a couple of small API updates:
>
> 1. Files.getAttribute and readAttributes currently return null (or an 
> empty map) when invoked with invalid attribute names. The proposed 
> change here fixes this so that IllegalArgumentException is thrown when 
> invalid names are used. UOE will continue to be throw if an 
> unsupported view is specified.
>
> 2. A method is added to WatchKey to return the the object for which 
> the watch key was created. This has come up several times, and the 
> implementation changes for this were actually included in the last 
> round of updates. For now the methods the Watchable and so must be 
> cast to the specific type when used. Not ideal but the alternative 
> propagates a type parameter and would require restricting the 
> WatchService so that it only watches objects of one type.
>
> 3. The Files.createTempFile and createTemptDirectory methods that 
> specify the temporary file directory are restricted to the default 
> file system. The rational for this is that it may not be possible to 
> generate a file name suitable for use with a custom file system. In 
> the future we can extend the provider interface to support this if 
> needed.
>
> 4. A couple of questions/inconsistencies were observed with the zip 
> provider when comparing paths in different zip file systems. To 
> address this, Path.equals is changed so that it returns false if the 
> given object is a Path associated with a different FileSystem (used to 
> return false if associated with a different provider). The 
> startsWith/endsWith methods also return false if the given path is 
> associated with a different FileSystem. This also addressed another 
> concern that came up no this mailing list some time ago where 
> ProviderMismatchException is thrown.
>
> The webrev with the changes is here:
>  http://cr.openjdk.java.net/~alanb/7017446/webrev/
>
> Thanks,
> Alan
Thanks, Alan, for implementing the change to WatchKey. Of the possible 
trade-offs regarding the return type, the one you made is probably the 
easiest to work with.

I also support the other API changes and had a look at the code changes 
which all look ok to me.

Wolfgang.