All Implemented Interfaces:
Flushable, OptionChecker, Closeable
All Known Implementing Classes:
ForwardingJavaFileManager, StandardJavaFileManager
When constructing new JavaFileObjects, the file manager must determine where to create them. For example, if a file manager manages regular files on a file system, it would most likely have a current/working directory to use as default location when creating or finding files. A number of hints can be provided to a file manager as to where to create files. Any file manager might choose to ignore these hints.
Some methods in this interface use class names. Such class names must be given in the Java Virtual Machine internal form of fully qualified class and interface names. For convenience '.' and '/' are interchangeable. The internal form is defined in chapter four of The Java™ Virtual Machine Specification.
Discussion: this means that the names "java/lang.package-info", "java/lang/package-info", "java.lang.package-info", are valid and equivalent. Compare to binary name as defined in The Java™ Language Specification, section 13.1 "The Form of a Binary".
The case of names is significant. All names should be treated as case-sensitive. For example, some file systems have case-insensitive, case-aware file names. File objects representing such files should take care to preserve case by using java.io.File#getCanonicalFile or similar means. If the system is not case-aware, file objects must use other means to preserve case.
Relative names: some methods in this interface use relative names. A relative name is a non-null, non-empty sequence of path segments separated by '/'. '.' or '..' are invalid path segments. A valid relative name must match the "path-rootless" rule of RFC 3986, section 3.3. Informally, this should be true:
URI.{@linkplain java.net.URI#create create}(relativeName).{@linkplain java.net.URI#normalize normalize}().{@linkplain java.net.URI#getPath getPath}().equals(relativeName)
All methods in this interface might throw a SecurityException.
An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object.
Implementation note: a consequence of this requirement is that a trivial implementation of output to a {@linkplain java.util.jar.JarOutputStream} is not a sufficient implementation. That is, rather than creating a JavaFileObject that returns the JarOutputStream directly, the contents must be cached until closed and then written to the JarOutputStream.
Unless explicitly allowed, all methods in this interface might throw a NullPointerException if given a {@code null} argument.
Peter
- von der AhéJonathan
- Gibbons1.6
- Nested Class Summary: | ||
---|---|---|
interface | JavaFileManager.Location | Interface for locations of file objects. Used by file managers to determine where to place or search for file objects. |
Method from javax.tools.JavaFileManager Summary: |
---|
close, flush, getClassLoader, getFileForInput, getFileForOutput, getJavaFileForInput, getJavaFileForOutput, handleOption, hasLocation, inferBinaryName, isSameFile, list |
Method from javax.tools.JavaFileManager Detail: |
---|
|
|
|
If the returned object represents a {@linkplain JavaFileObject.Kind#SOURCE source} or {@linkplain JavaFileObject.Kind#CLASS class} file, it must be an instance of JavaFileObject . Informally, the file object returned by this method is located in the concatenation of the location, package name, and relative name. For example, to locate the properties file "resources/compiler.properties" in the package "com.sun.tools.javac" in the {@linkplain StandardLocation#SOURCE_PATH SOURCE_PATH} location, this method might be called like so: getFileForInput(SOURCE_PATH, "com.sun.tools.javac", "resources/compiler.properties"); If the call was executed on Windows, with SOURCE_PATH set to
|
Optionally, this file manager might consider the sibling as a hint for where to place the output. The exact semantics of this hint is unspecified. The JDK compiler, javac, for example, will place class files in the same directories as originating source files unless a class file output directory is provided. To facilitate this behavior, javac might provide the originating source file as sibling when calling this method. If the returned object represents a {@linkplain JavaFileObject.Kind#SOURCE source} or {@linkplain JavaFileObject.Kind#CLASS class} file, it must be an instance of JavaFileObject . Informally, the file object returned by this method is located in the concatenation of the location, package name, and relative name or next to the sibling argument. See getFileForInput for an example. |
|
Optionally, this file manager might consider the sibling as a hint for where to place the output. The exact semantics of this hint is unspecified. The JDK compiler, javac, for example, will place class files in the same directories as originating source files unless a class file output directory is provided. To facilitate this behavior, javac might provide the originating source file as sibling when calling this method. |
|
|
|
|
Note: even if the given location is unknown to this file manager, it may not return {@code null}. Also, an unknown location may not cause an exception. |