JDK-8218875 : (fs) Add FileSystems.newFileSystem(Path, Map) method
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-02-12
  • Updated: 2019-07-01
  • Resolved: 2019-05-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b20Fixed
Related Reports
CSR :  
JDK-8219793 - (fs) Add FileSystems.newFileSystem(Path, Map) method
Relates :  
JDK-8223771 - (zipfs) FileSystemProvider.newFileSystem(Path, Map) should throw IOException when called with a file that cannot be open
Sub Tasks
JDK-8223197 :  
Release Note: Added FileSystems.newFileSystem(Path, Map<String, ?>) Method - Closed
Description
Now that the Zip File System is supported, we should add

FileSystems.newFIleSystem(Path, Map<String, ?>) throws IOException
FileSystems.newFileSystem(Path path, Map<String,?> env,  ClassLoader loader) throws IOException

to make it easer for developers
Comments
The Zip FileSystem has always thrown a FileSystemNotFoundException when the jar/zip in the specified path does not exist and the create Property is not set to true when newFileSystem is called. The existing newFileSystem methods, including the URI based methods will also throw FileSystemNotFoundException so this is not new behavior. There needs to be a discussion as to whether the Zip FileSystem should continue to throw FileSystemAlreadyExistsException or changed to an IOException and then the javadocs can be updated if needed. This is a separate task from the addition of these methods. FileSystemAlreadyExistsException should not be thrown via the newFileSystem(Path ...) methods and the Zip FileSystem only throws this when required when newFileSystem(URI...) is called.
09-05-2019
[~lancea] Spec does not mention about FileSystemNotFoundException which can be thrown by these 3 new methods. E.g. FileSystems.newFileSystem(Path.of("NonExistentJarFile.jar")) Should "throws FileSystemNotFoundException" be added to spec? Also, is it possible that these methods can throw "FileSystemAlreadyExistsException" and can be added to spec? [~dbessono]
08-05-2019
Ok, still there is this source incompatibility for calls to FileSytems.newFileSystem(Path, null). I guess there are people out who call this because they simply can't call FileSytems.newFileSystem(Path). Do you really think this is so rare that there's no big issue when introducing FileSystems.newFIleSystem(Path, Map<String, ?>)? BTW: We should also offer FileSystems.newFIleSystem(Path).
20-02-2019
There is no reason to deprecate newFileSystem(Path, ClassLoader), overloads are okay.
20-02-2019
But for that you'd then have FileSytems.newFileSystem(Path, Map, ClassLoader) or FileSytems.of(Path, Map, ClassLoader), no?
20-02-2019
newFileSystem(Path, ClassLoader) should not be deprecated - it is needed for custom file system provider (TrueZIP comes to mind) that may not be visible via the system class loader.
20-02-2019
What about having FileSystems.of(Path, ...)? In any case, FileSytems.newFileSystem(Path, ClassLoader) should be deprecated then.
20-02-2019
newFileSystem(Path, ClassLoader) is for niche cases where a file is opened as a file system. When we looked at previously, we concluded that newFileSystem(Path, null) should be rare and the source incompatibility may not be a big issue. Introducing methods where the parameters are reordered or with different names would be a ugly so we've been trying to avoid that if we can.
20-02-2019
The convenience is not having to create a URI from the Path to call one of the existing methods. As seen in the webrev, adding these methods will be source incompatible due to the ambiguity of null as the second argument.
19-02-2019