File manager based on
java.io.File
and
java.nio.file.Path
. A common way to obtain an instance of this class is using
getStandardFileManager, for example:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
DiagnosticCollector<JavaFileObject>
diagnostics =
new DiagnosticCollector<JavaFileObject>()
;
StandardJavaFileManager fm = compiler.getStandardFileManager(diagnostics, null, null);
This file manager creates file objects representing regular
files,
zip file entries , or entries in similar file system based containers. Any file object returned from a file manager implementing this interface must observe the following behavior:
- File names need not be canonical.
-
For file objects representing regular files
-
The URI returned from
FileObject.toUri()
-
must be absolute (have a schema), and
-
must have a normalizedpath component which can be resolved without any process-specific context such as the current directory (file names must be absolute).
According to these rules, the following URIs, for example, are allowed:
-
file:///C:/Documents%20and%20Settings/UncleBob/BobsApp/Test.java
-
jar:///C:/Documents%20and%20Settings/UncleBob/lib/vendorA.jar!/com/vendora/LibraryClass.class
Whereas these are not (reason in parentheses):
-
file:BobsApp/Test.java
(the file name is relative and depend on the current directory)
-
jar:lib/vendorA.jar!/com/vendora/LibraryClass.class
(the first half of the path depends on the current directory, whereas the component after ! is legal)
-
Test.java
(this URI depends on the current directory and does not have a schema)
-
jar:///C:/Documents%20and%20Settings/UncleBob/BobsApp/../lib/vendorA.jar!com/vendora/LibraryClass.class
(the path is not normalized)
All implementations of this interface must support Path objects representing files in the default file system. It is recommended that implementations should support Path objects from any filesystem.
getJavaFileObjectsFromPaths(Collection)
instead, to prevent the possibility of accidentally calling the method with a singlePath
as such an argument. AlthoughPath
implementsIterable<Path>
, it would almost never be correct to pass a singlePath
and have it be treated as anIterable
of its components.