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();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:DiagnosticCollector<JavaFileObject>diagnostics = newDiagnosticCollector<JavaFileObject>(); StandardJavaFileManager fm = compiler.getStandardFileManager(diagnostics, null, null);
FileObject.delete()
is equivalent to File.delete(),
FileObject.getLastModified()
is equivalent to File.lastModified(),
FileObject.getCharContent(boolean),
FileObject.openInputStream(), and
FileObject.openReader(boolean)
must succeed if the following would succeed (ignoring
encoding issues):
new FileInputStream(new File(fileObject.toUri()))
FileObject.openOutputStream(), and
FileObject.openWriter() must
succeed if the following would succeed (ignoring encoding
issues):
new FileOutputStream(new File(fileObject.toUri()))
FileObject.toUri()
file:///C:/Documents%20and%20Settings/UncleBob/BobsApp/Test.java
jar:///C:/Documents%20and%20Settings/UncleBob/lib/vendorA.jar!/com/vendora/LibraryClass.class
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.
extends
@apiNote
Some methods on this interface take a Collection<? extends Path>
instead of Iterable<? extends Path>.
This is to prevent the possibility of accidentally calling the method
with a single Path as such an argument, because although
Path implements Iterable<Path>, it would almost never be
correct to call these methods with a single Path and have it be treated as
an Iterable of its components.