Interface for diagnostics from tools.  A diagnostic usually reports
a problem at a specific position in a source file.  However, not
all diagnostics are associated with a position or a file.

A position is a zero-based character offset from the beginning of
a file.  Negative values (except NOPOS) are not valid
positions.

Line and column numbers begin at 1.  Negative values (except
NOPOS) and 0 are not valid line or column numbers.

Provides an easy way to collect diagnostics in a list.

Interface for receiving diagnostics from tools.

Interface to invoke Java™ programming language documentation tools from
programs.

Interface representing a future for a documentation task.  The
task has not yet started.  To start the task, call
the call method.

Before calling the call method, additional aspects of the
task can be configured, for example, by calling the
setLocale method.

File abstraction for tools.  In this context, file means
an abstraction of regular files and other sources of data.  For
example, a file object can be used to represent regular files,
memory cache, or data in databases.

All methods in this interface might throw a SecurityException if
a security exception occurs.

Unless explicitly allowed, all methods in this interface might
throw a NullPointerException if given a null argument.

Forwards calls to a given file object.  Subclasses of this class
might override some of these methods and might also provide
additional fields and methods.

Forwards calls to a given file manager.  Subclasses of this class
might override some of these methods and might also provide
additional fields and methods.

Forwards calls to a given file object.  Subclasses of this class
might override some of these methods and might also provide
additional fields and methods.

Every compiler which implements this interface provides a
standard file manager for operating on regular java.io.files.  The StandardJavaFileManager interface
defines additional methods for creating file objects from
regular files.

The standard file manager serves two purposes:


  basic building block for customizing how a compiler reads
  and writes files
  sharing between multiple compilation tasks


Reusing a file manager can potentially reduce overhead of
scanning the file system and reading jar files.  Although there
might be no reduction in overhead, a standard file manager must
work with multiple sequential compilations making the following
example a recommended coding pattern:



  File[] files1 = ... ; // input for first compilation task
  File[] files2 = ... ; // input for second compilation task

  JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
  StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null);

   Iterable<? extends JavaFileObject> compilationUnits1 =
      fileManager.getJavaFileObjectsFromFiles(Arrays.asList(files1));
  compiler.getTask(null, fileManager, null, null, null, compilationUnits1).call();

   Iterable<? extends JavaFileObject> compilationUnits2 =
      fileManager.getJavaFileObjects(files2); // use alternative method
  // reuse the same file manager to allow caching of jar files
  compiler.getTask(null, fileManager, null, null, null, compilationUnits2).call();

  fileManager.close();

Used to collect diagnostics in a list, for example:


   Iterable<? extends JavaFileObject> compilationUnits = ...;
  JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
   DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<JavaFileObject>();
  StandardJavaFileManager fileManager = compiler.getStandardFileManager(diagnostics, null, null);
  compiler.getTask(null, fileManager, diagnostics, null, null, compilationUnits).call();

  for ( Diagnostic<? extends JavaFileObject> diagnostic : diagnostics.getDiagnostics())
      System.out.format("Error on line %d in %s%n",
                        diagnostic.getLineNumber(),
                        diagnostic.getSource().toUri());

  fileManager.close();



ForwardingJavaFileManager, ForwardingFileObject, and
ForwardingJavaFileObject



Subclassing is not available for overriding the behavior of a
standard file manager as it is created by calling a method on a
compiler, not by invoking a constructor.  Instead forwarding
(or delegation) should be used.  These classes makes it easy to
forward most calls to a given file manager or file object while
allowing customizing behavior.  For example, consider how to
log all calls to JavaFileManager.flush():



  final java.util.logging.Logger logger = ...;
   Iterable<? extends JavaFileObject> compilationUnits = ...;
  JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
  StandardJavaFileManager stdFileManager = compiler.getStandardFileManager(null, null, null);
  JavaFileManager fileManager = new ForwardingJavaFileManager(stdFileManager) {
      public void flush() throws IOException {
          logger.entering(StandardJavaFileManager.class.getName(), "flush");
          super.flush();
          logger.exiting(StandardJavaFileManager.class.getName(), "flush");
      }
  };
  compiler.getTask(null, fileManager, null, null, null, compilationUnits).call();

This class provides a basic file object implementation which
can be used as building block for creating file objects.  For
example, here is how to define a file object which represent
source code stored in a string:



  /**
   * A file object used to represent source coming from a string.
    */
  public class JavaSourceFromString extends SimpleJavaFileObject {
      /**
       * The source code of this "file".
        */
      final String code;

      /**
       * Constructs a new JavaSourceFromString.
       *  @param name the name of the compilation unit represented by this file object
       *  @param code the source code for the compilation unit represented by this file object
        */
      JavaSourceFromString(String name, String code) {
          super(URI.create("string:///"  name.replace('.','/')  Kind.SOURCE.extension),
                Kind.SOURCE);
          this.code = code;
      }

       @Override
      public CharSequence getCharContent(boolean ignoreEncodingErrors) {
          return code;
      }
  }

Interface to invoke Java™ programming language compilers from
programs.

The compiler might generate diagnostics during compilation (for
example, error messages).  If a diagnostic listener is provided,
the diagnostics will be supplied to the listener.  If no listener
is provided, the diagnostics will be formatted in an unspecified
format and written to the default output, which is System.err unless otherwise specified.  Even if a diagnostic
listener is supplied, some diagnostics might not fit in a Diagnostic and will be written to the default output.

A compiler tool has an associated standard file manager, which
is the file manager that is native to the tool (or built-in).  The
standard file manager can be obtained by calling getStandardFileManager.

A compiler tool must function with any file manager as long as
any additional requirements as detailed in the methods below are
met.  If no file manager is provided, the compiler tool will use a
standard file manager such as the one returned by getStandardFileManager.

An instance implementing this interface must conform to
The Java™ Language Specification
and generate class files conforming to
The Java™ Virtual Machine Specification.
The versions of these
specifications are defined in the javax.tools.Tool interface.

Additionally, an instance of this interface supporting SourceVersion.RELEASE_6
or higher must also support annotation processing.

The compiler relies on two services: javax.tools.diagnostic listener and javax.tools.file manager.  Although most classes and
interfaces in this package defines an API for compilers (and
tools in general) the interfaces javax.tools.DiagnosticListener,
javax.tools.JavaFileManager, javax.tools.FileObject, and
javax.tools.JavaFileObject are not intended to be used in
applications.  Instead these interfaces are intended to be
implemented and used to provide customized services for a
compiler and thus defines an SPI for compilers.

There are a number of classes and interfaces in this package
which are designed to ease the implementation of the SPI to
customize the behavior of a compiler:


  StandardJavaFileManager


    Every compiler which implements this interface provides a
    standard file manager for operating on regular java.io.files.  The StandardJavaFileManager interface
    defines additional methods for creating file objects from
    regular files.

    The standard file manager serves two purposes:


      basic building block for customizing how a compiler reads
      and writes files
      sharing between multiple compilation tasks


    Reusing a file manager can potentially reduce overhead of
    scanning the file system and reading jar files.  Although there
    might be no reduction in overhead, a standard file manager must
    work with multiple sequential compilations making the following
    example a recommended coding pattern:



      File[] files1 = ... ; // input for first compilation task
      File[] files2 = ... ; // input for second compilation task

      JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
      StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null);

       Iterable<? extends JavaFileObject> compilationUnits1 =
          fileManager.getJavaFileObjectsFromFiles(Arrays.asList(files1));
      compiler.getTask(null, fileManager, null, null, null, compilationUnits1).call();

       Iterable<? extends JavaFileObject> compilationUnits2 =
          fileManager.getJavaFileObjects(files2); // use alternative method
      // reuse the same file manager to allow caching of jar files
      compiler.getTask(null, fileManager, null, null, null, compilationUnits2).call();

      fileManager.close();



  DiagnosticCollector

    Used to collect diagnostics in a list, for example:


       Iterable<? extends JavaFileObject> compilationUnits = ...;
      JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
       DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<JavaFileObject>();
      StandardJavaFileManager fileManager = compiler.getStandardFileManager(diagnostics, null, null);
      compiler.getTask(null, fileManager, diagnostics, null, null, compilationUnits).call();

      for ( Diagnostic<? extends JavaFileObject> diagnostic : diagnostics.getDiagnostics())
          System.out.format("Error on line %d in %s%n",
                            diagnostic.getLineNumber(),
                            diagnostic.getSource().toUri());

      fileManager.close();



    ForwardingJavaFileManager, ForwardingFileObject, and
    ForwardingJavaFileObject



    Subclassing is not available for overriding the behavior of a
    standard file manager as it is created by calling a method on a
    compiler, not by invoking a constructor.  Instead forwarding
    (or delegation) should be used.  These classes makes it easy to
    forward most calls to a given file manager or file object while
    allowing customizing behavior.  For example, consider how to
    log all calls to JavaFileManager.flush():



      final java.util.logging.Logger logger = ...;
       Iterable<? extends JavaFileObject> compilationUnits = ...;
      JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
      StandardJavaFileManager stdFileManager = compiler.getStandardFileManager(null, null, null);
      JavaFileManager fileManager = new ForwardingJavaFileManager(stdFileManager) {
          public void flush() throws IOException {
              logger.entering(StandardJavaFileManager.class.getName(), "flush");
              super.flush();
              logger.exiting(StandardJavaFileManager.class.getName(), "flush");
          }
      };
      compiler.getTask(null, fileManager, null, null, null, compilationUnits).call();


  SimpleJavaFileObject


    This class provides a basic file object implementation which
    can be used as building block for creating file objects.  For
    example, here is how to define a file object which represent
    source code stored in a string:



      /**
       * A file object used to represent source coming from a string.
        */
      public class JavaSourceFromString extends SimpleJavaFileObject {
          /**
           * The source code of this "file".
            */
          final String code;

          /**
           * Constructs a new JavaSourceFromString.
           *  @param name the name of the compilation unit represented by this file object
           *  @param code the source code for the compilation unit represented by this file object
            */
          JavaSourceFromString(String name, String code) {
              super(URI.create("string:///"  name.replace('.','/')  Kind.SOURCE.extension),
                    Kind.SOURCE);
              this.code = code;
          }

           @Override
          public CharSequence getCharContent(boolean ignoreEncodingErrors) {
              return code;
          }
      }

Interface representing a future for a compilation task.  The
compilation task has not yet started.  To start the task, call
the call method.

Before calling the call method, additional aspects of the
task can be configured, for example, by calling the
setProcessors method.

File manager for tools operating on Java™ programming language
source and class files.  In this context, file means an
abstraction of regular files and other sources of data.

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 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.create(relativeName).normalize().getPath().equals(relativeName)


 URI.create(relativeName).normalize().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 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 null argument.

Interface for locations of file objects.  Used by file managers
to determine where to place or search for file objects.

File abstraction for tools operating on Java™ programming language
source and class files.

All methods in this interface might throw a SecurityException if
a security exception occurs.

Unless explicitly allowed, all methods in this interface might
throw a NullPointerException if given a null argument.

Interface for recognizing options.

Provides simple implementations for most methods in JavaFileObject.
This class is designed to be subclassed and used as a basis for
JavaFileObject implementations.  Subclasses can override the
implementation and specification of any method of this class as
long as the general contract of JavaFileObject is obeyed.

 File names need not be canonical.


 For file objects representing regular files


     the method FileObject.delete()
     is equivalent to File.delete(),


     the method FileObject.getLastModified()
     is equivalent to File.lastModified(),


     the methods FileObject.getCharContent(boolean),
     FileObject.openInputStream(), and
     FileObject.openReader(boolean)
     must succeed if the following would succeed (ignoring
     encoding issues):

     and the methods
     FileObject.openOutputStream(), and
     FileObject.openWriter() must
     succeed if the following would succeed (ignoring encoding
     issues):

 The java.net.URI returned from
 FileObject.toUri()


     must be absolute (have a schema), and


     must have a normalized
     path component which
     can be resolved without any process-specific context such
     as the current directory (file names must be absolute).

 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)

File manager based on java.io.java$io$File.  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
 java.io.files,
 java.util.zip.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 method FileObject.delete()
         is equivalent to File.delete(),


         the method FileObject.getLastModified()
         is equivalent to File.lastModified(),


         the methods FileObject.getCharContent(boolean),
         FileObject.openInputStream(), and
         FileObject.openReader(boolean)
         must succeed if the following would succeed (ignoring
         encoding issues):



new FileInputStream(new File(javax.tools.fileObject.toUri()))



         and the methods
         FileObject.openOutputStream(), and
         FileObject.openWriter() must
         succeed if the following would succeed (ignoring encoding
         issues):



new FileOutputStream(new File(javax.tools.fileObject.toUri()))





     The java.net.URI returned from
     FileObject.toUri()


         must be absolute (have a schema), and


         must have a normalized
         path 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)

Common interface for tools that can be invoked from a program.
A tool is traditionally a command line program such as a compiler.
The set of tools available with a platform is defined by the
vendor.

Tools can be located using ServiceLoader.load(Class).

Provides methods for locating tool providers, for example,
providers of compilers.  This class complements the
functionality of ServiceLoader.