1 ---
   2 # Copyright (c) 1994, 2025, Oracle and/or its affiliates. All rights reserved.
   3 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   4 #
   5 # This code is free software; you can redistribute it and/or modify it
   6 # under the terms of the GNU General Public License version 2 only, as
   7 # published by the Free Software Foundation.
   8 #
   9 # This code is distributed in the hope that it will be useful, but WITHOUT
  10 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11 # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12 # version 2 for more details (a copy is included in the LICENSE file that
  13 # accompanied this code).
  14 #
  15 # You should have received a copy of the GNU General Public License version
  16 # 2 along with this work; if not, write to the Free Software Foundation,
  17 # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18 #
  19 # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20 # or visit www.oracle.com if you need additional information or have any
  21 # questions.
  22 #
  23 
  24 title: 'JAVAC(1) JDK @@VERSION_SHORT@@ | JDK Commands'
  25 date: @@COPYRIGHT_YEAR@@
  26 lang: en
  27 ---
  28 
  29 ## Name
  30 
  31 javac - read Java declarations and compile them into class files
  32 
  33 ## Synopsis
  34 
  35 `javac` \[*options*\] \[*sourcefiles-or-classnames*\]
  36 
  37 *options*
  38 :   Command-line options.
  39 
  40 *sourcefiles-or-classnames*
  41 :   Source files to be compiled (for example, `Shape.java`) or
  42     the names of previously compiled classes to be processed for annotations
  43     (for example, `geometry.MyShape`).
  44 
  45 ## Description
  46 
  47 The `javac` command reads _source files_ that contain module, package and type
  48 declarations written in the Java programming language, and compiles them into _class files_
  49 that run on the Java Virtual Machine.
  50 
  51 The `javac` command can also [process annotations](#annotation-processing)
  52 in Java source files and classes.
  53 
  54 Source files must have a file name extension of `.java`.
  55 Class files have a file name extension of `.class`.
  56 Both source and class files normally have file names that identify the contents.
  57 For example, a class called `Shape` would be declared in a source file
  58 called `Shape.java`, and compiled into a class file called `Shape.class`.
  59 
  60 There are two ways to specify source files to `javac`:
  61 
  62 - For a small number of source files, you can list their file names on
  63   the command line.
  64 
  65 - For a large number of source files, you can use the [`@`*filename*](#option-at)
  66   option on the command line to specify an _argument file_ that lists
  67   their file names. See [Standard Options] for a description of the
  68   option and [Command-Line Argument Files] for a description of
  69   `javac` argument files.
  70 
  71 The order of source files specified on the command line or in an
  72 argument file is not important. `javac` will compile the files together,
  73 as a group, and will automatically resolve any dependencies between
  74 the declarations in the various source files.
  75 
  76 `javac` expects that source files are arranged in one or more directory
  77 hierarchies on the file system, described in [Arrangement of Source
  78 Code].
  79 
  80 To compile a source file, `javac` needs to find the declaration of
  81 every class or interface that is used, extended, or implemented by the
  82 code in the source file. This lets `javac` check that the code has the
  83 right to access those classes and interfaces. Rather than specifying
  84 the source files of those classes and interfaces explicitly, you can
  85 use command-line options to tell `javac` where to search for their
  86 source files. If you have compiled those source files previously, you
  87 can use options to tell `javac` where to search for the corresponding
  88 class files. The options, which all have names ending in "path", are
  89 described in [Standard Options], and further described in
  90 [Configuring a Compilation] and [Searching for Module, Package and Type Declarations].
  91 
  92 By default, `javac` compiles each source file to a class file in the
  93 same directory as the source file. However, it is recommended to
  94 specify a separate destination directory with the [`-d`](#option-d) option.
  95 
  96 Command-line [options] and [environment variables] also control how
  97 `javac` performs various tasks:
  98 
  99 - Compiling code to run on earlier releases of the JDK.
 100 - Compiling code to run under a debugger.
 101 - Checking for stylistic issues in Java source code.
 102 - Checking for problems in `javadoc` comments (`/** ... */`).
 103 - Processing annotations in source files and class files.
 104 - Upgrading and patching modules in the compile-time environment.
 105 
 106 `javac` supports [Compiling for Earlier Releases Of The Platform]
 107 and can also be invoked from Java code using one of a number of [APIs]
 108 
 109 ## Options
 110 
 111 `javac` provides [standard options], and [extra options] that are either
 112 non-standard or are for advanced use.
 113 
 114 Some options take one or more arguments.
 115 If an argument contains spaces or other whitespace characters,
 116 the value should be quoted according to the conventions of the
 117 environment being used to invoke javac.
 118 If the option begins with a single dash (`-`) the argument should
 119 either directly follow the option name, or should be separated with a
 120 colon (`:`) or whitespace, depending on the option. If the option begins with
 121 a double dash (`--`), the argument may be separated either by whitespace
 122 or by an equals (`=`) character with no additional whitespace.
 123 For example,
 124 
 125     -Aname="J. Duke"
 126     -proc:only
 127     -d myDirectory
 128     --module-version 3
 129     --module-version=3
 130 
 131 In the following lists of options, an argument of *path* represents
 132 a search path, composed of a list of file system locations separated
 133 by the platform path separator character, (semicolon `;` on Windows,
 134 or colon `:` on other systems.) Depending on the option, the
 135 file system locations may be directories, JAR files or JMOD files.
 136 
 137 ### Standard Options
 138 
 139 <a id="option-at">`@`*filename*</a>
 140 :   Reads options and file names from a file. To shorten or simplify the
 141     `javac` command, you can specify one or more files that contain arguments
 142     to the `javac` command (except [`-J`](#option-J) options). This lets you to create
 143     `javac` commands of any length on any operating system.
 144     See [Command-Line Argument Files].
 145 
 146 <a id="option-A">`-A`*key*\[`=`*value*\]</a>
 147 :   Specifies options to pass to annotation processors. These options are not
 148     interpreted by `javac` directly, but are made available for use by
 149     individual processors. The *key* value should be one or more identifiers
 150     separated by a dot (`.`).
 151 
 152 <a id="option-add-modules">`--add-modules` *module*`,`*module*</a>
 153 :   Specifies root modules to resolve in addition to the initial modules, or
 154     all modules on the module path if *module* is `ALL-MODULE-PATH`.
 155 
 156 <a id="option-boot-class-path">`--boot-class-path` *path* or `-bootclasspath` *path*</a>
 157 :   Overrides the location of the bootstrap class files.
 158 
 159     **Note:** This can only be used when compiling for releases prior to JDK 9.
 160     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source), or
 161     [`-target`](#option-target) for details.  For JDK 9 or later, see [`--system`](#option-system).
 162 
 163 <a id="option-class-path">`--class-path` *path*, `-classpath` *path*, or `-cp` *path*</a>
 164 :   Specifies where to find user class files and annotation processors. This
 165     class path overrides the user class path in the `CLASSPATH` environment
 166     variable.
 167 
 168     -   If `--class-path`, `-classpath`, or `-cp` are not specified, then the
 169         user class path is the value of the `CLASSPATH` environment variable,
 170         if that is set, or else the current directory.
 171 
 172     -   If not compiling code for modules, if the [`--source-path`](#option-source-path) or -sourcepath`
 173         option is not specified, then the user class path is also searched for source files.
 174 
 175     -   If the [`-processorpath`](#option-processor-path) option is not specified, then the class path is
 176         also searched for annotation processors.
 177 
 178 <a id="option-d">`-d` *directory*</a>
 179 :   Sets the destination directory (or _class output directory_) for class files.
 180     If a class is part of a package, then `javac` puts the class file in a
 181     subdirectory that reflects the module name (if appropriate) and package name.
 182     The directory, and any necessary subdirectories, will be created if they
 183     do not already exist.
 184 
 185     If the `-d` option is not specified, then `javac` puts each class file in
 186     the same directory as the source file from which it was generated.
 187 
 188     Except when compiling code for multiple modules, the contents of the
 189     class output directory will be organized in a package hierarchy.
 190     When compiling code for multiple modules, the contents of the output
 191     directory will be organized in a module hierarchy, with the contents of each
 192     module in a separate subdirectory, each organized as a package
 193     hierarchy.
 194 
 195     **Note:**
 196     When compiling code for one or more modules, the class output directory will
 197     automatically be checked when searching for previously compiled classes.
 198     When not compiling for modules, for backwards compatibility,
 199     the directory is _not_ automatically checked for previously compiled classes,
 200     and so it is recommended to specify the class output directory as one
 201     of the locations on the user class path, using the `--class-path` option or one of
 202     its alternate forms.
 203 
 204 <a id="option-deprecation">`-deprecation`</a>
 205 :   Shows a description of each use or override of a deprecated member or
 206     class. Without the `-deprecation` option, `javac` shows a summary of the
 207     source files that use or override deprecated members or classes. The
 208     `-deprecation` option is shorthand for `-Xlint:deprecation`.
 209 
 210 <a id="option-enable-preview">`--enable-preview`</a>
 211 :   Enables preview language features. Also disables the `preview` lint category.
 212     Used in conjunction with either [`-source`](#option-source) or [`--release`](#option-release).
 213 
 214 <a id="option-encoding">`-encoding` *encoding*</a>
 215 :   Specifies character encoding used by source files, such as EUC-JP and
 216     UTF-8. If the `-encoding` option is not specified, then the platform default
 217     converter is used.
 218 
 219 <a id="option-endorseddirs">`-endorseddirs` *directories*</a>
 220 :   Overrides the location of the endorsed standards path.
 221 
 222     **Note:** This can only be used when compiling for releases prior to JDK 9.
 223     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source), or
 224     [`-target`](#option-target) for details.
 225 
 226 <a id="option-extdirs">`-extdirs` *directories*</a>
 227 :   Overrides the location of the installed extensions.
 228     `directories` is a list of directories, separated by the platform path separator
 229     (`;` on Windows, and `:` otherwise).
 230     Each JAR file in the specified directories is searched for class files.
 231     All JAR files found become part of the class path.
 232 
 233     If you are compiling for a release of the platform that supports the
 234     Extension Mechanism, then this option specifies the directories that
 235     contain the extension classes.
 236     See [Compiling for Other Releases of the Platform].
 237 
 238     **Note:** This can only be used when compiling for releases prior to JDK 9.
 239     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source), or
 240     [`-target`](#option-target) for details.
 241 
 242 <a id="option-g">`-g`</a>
 243 :   Generates all debugging information, including local variables. By default,
 244     only line number and source file information is generated.
 245 
 246 <a id="option-g-custom">`-g:`\[`lines`, `vars`, `source`\]</a>
 247 :   Generates only the kinds of debugging information specified by the
 248     comma-separated list of keywords. Valid keywords are:
 249 
 250     `lines`
 251     :   Line number debugging information.
 252 
 253     `vars`
 254     :   Local variable debugging information.
 255 
 256     `source`
 257     :   Source file debugging information.
 258 
 259 <a id="option-g-none">`-g:none`</a>
 260 :   Does not generate debugging information.
 261 
 262 <a id="option-h">`-h` *directory*</a>
 263 :   Specifies where to place generated native header files.
 264 
 265     When you specify this option, a native header file is generated for each
 266     class that contains native methods or that has one or more constants
 267     annotated with the [`java.lang.annotation.Native`](
 268     ../../api/java.base/java/lang/annotation/Native.html)
 269     annotation. If the class is part of a package, then the compiler puts the
 270     native header file in a subdirectory that reflects the module name
 271     (if appropriate) and package name.
 272     The directory, and any necessary subdirectories, will be created if they
 273     do not already exist.
 274 
 275 <a id="option-help">`--help`, `-help` or `-?`</a>
 276 :   Prints a synopsis of the standard options.
 277 
 278 <a id="option-help-extra">`--help-extra` or `-X`</a>
 279 :   Prints a synopsis of the set of extra options.
 280 
 281 <a id="option-help-lint">`--help-lint`</a>
 282 :   Prints the supported keys for the `-Xlint` option.
 283 
 284 <a id="option-implicit">`-implicit:`\[`none`, `class`\]</a>
 285 :   Specifies whether or not to generate class files for implicitly referenced
 286     files:
 287 
 288     -   `-implicit:class` --- Automatically generates class files.
 289 
 290     -   `-implicit:none` --- Suppresses class file generation.
 291 
 292     If this option is not specified, then the default automatically generates
 293     class files. In this case, the compiler issues a warning if any class files
 294     are generated when also doing annotation processing. The warning is not
 295     issued when the `-implicit` option is explicitly set.
 296     See [Searching for Module, Package and Type Declarations].
 297 
 298 <a id="option-J">`-J`*option*</a>
 299 :   Passes *option* to the runtime system, where *option* is one of the Java
 300     options described on [java](java.html) command. For example, `-J-Xms48m`
 301     sets the startup memory to 48 MB.
 302 
 303     **Note:** The `CLASSPATH` environment variable, `-classpath` option, `-bootclasspath`
 304     option, and `-extdirs` option do not specify the classes used to run
 305     `javac`. Trying to customize the compiler implementation with these options
 306     and variables is risky and often does not accomplish what you want. If you
 307     must customize the compiler implementation, then use the `-J` option to
 308     pass options through to the underlying Java launcher.
 309 
 310 <a id="option-limit-modules">`--limit-modules` *module*`,`*module*\*</a>
 311 :   Limits the universe of observable modules.
 312 
 313 <a id="option-module">`--module` *module-name* (`,`*module-name*)* or `-m` *module-name* (`,`*module-name*)*</a>
 314 :   Compiles those source files in the named modules that are newer
 315     than the corresponding files in the output directory.
 316 
 317 <a id="option-module-path">`--module-path` *path* or `-p` *path*</a>
 318 :   Specifies where to find application modules.
 319 
 320 <a id="option-module-source-path">`--module-source-path` *module-source-path*</a>
 321 :   Specifies where to find source files when compiling code
 322     in multiple modules. See [The Module Source Path Option].
 323 
 324 <a id="option-module-version">`--module-version` *version*</a>
 325 :   Specifies the version of modules that are being compiled.
 326 
 327 <a id="option-nowarn">`-nowarn`</a>
 328 :   Generate only mandatory warnings.
 329 
 330 <a id="option-parameters">`-parameters`</a>
 331 :   Generates metadata for reflection on method parameters. Stores formal
 332     parameter names of constructors and methods in the generated class file so
 333     that the method `java.lang.reflect.Executable.getParameters` from the
 334     Reflection API can retrieve them.
 335 
 336 <a id="option-proc">`-proc:`\[`none`, `only`, `full`\]</a>
 337 :   Controls whether annotation processing and compilation are done.
 338 
 339     -   `-proc:none` means that compilation takes place without annotation
 340     processing
 341 
 342     -   `-proc:only` means that only annotation processing is done,
 343     without any subsequent compilation.
 344 
 345     -   `-proc:full` means annotation processing and compilation are done.
 346 
 347     If this option is not used, annotation processing and compilation
 348     are done if at least one other option is used to explicitly
 349     configure annotation processing.
 350 
 351 <a id="option-processor">`-processor` *class1*\[`,`*class2*`,`*class3*...\]</a>
 352 :   Names of the annotation processors to run. This bypasses the default
 353     discovery process.
 354 
 355 <a id="option-processor-module-path">`--processor-module-path` *path*</a>
 356 :   Specifies the module path used for finding annotation processors.
 357 
 358 <a id="option-processor-path">`--processor-path` *path* or `-processorpath` *path*</a>
 359 :   Specifies where to find annotation processors. If this option is not used,
 360     then the class path is searched for processors.
 361 
 362 <a id="option-profile">`-profile` *profile*</a>
 363 :   Checks that the API used is available in the specified profile.
 364     This option is deprecated and may be removed in a future release.
 365 
 366     **Note:** This can only be used when compiling for releases prior to JDK 9.
 367     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 368     or [`-target`](#option-target) for details.
 369 
 370 <a id="option-release">`--release` *release*</a>
 371 :   Compiles source code according to the rules of the Java programming language
 372     for the specified Java SE release, generating class files which target
 373     that release.
 374     Source code is compiled against the combined Java SE and JDK API for the
 375     specified release.
 376 
 377     The supported values of *release* are the current Java SE release and a
 378     limited number of previous releases, detailed in the command-line help.
 379 
 380     For the current release, the Java SE API consists of the `java.*`,
 381     `javax.*`, and `org.*` packages that are exported by the Java SE modules in
 382     the release; the JDK API consists of the `com.*` and `jdk.*` packages that
 383     are exported by the JDK modules in the release, plus the `javax.*` packages
 384     that are exported by standard, but non-Java SE, modules in the release.
 385 
 386     For previous releases, the Java SE API and the JDK API are as defined in
 387     that release.
 388 
 389     **Note:** When using `--release`, you cannot also use the [`--source`](#option-source)/`-source` or
 390     [`--target`](#option-target)/`-target` options.
 391 
 392     **Note:** When using `--release` to specify a release that supports the Java
 393     Platform Module System, the `--add-exports` option cannot be used to
 394     enlarge the set of packages exported by the Java SE, JDK, and standard
 395     modules in the specified release.
 396 
 397 <a id="option-s">`-s` *directory*</a>
 398 :   Specifies the directory used to place the generated source files. If a
 399     class is part of a package, then the compiler puts the source file in a
 400     subdirectory that reflects the module name (if appropriate) and package name.
 401     The directory, and any necessary subdirectories, will be created if they
 402     do not already exist.
 403 
 404     Except when compiling code for multiple modules, the contents of the
 405     source output directory will be organized in a package hierarchy.
 406     When compiling code for multiple modules, the contents of the source output directory will be
 407     organized in a module hierarchy, with the contents of each
 408     module in a separate subdirectory, each organized as a package
 409     hierarchy.
 410 
 411 <a id="option-source">`--source` *release* or `-source` *release*</a>
 412 :   Compiles source code according to the rules of the Java programming language
 413     for the specified Java SE release.
 414     The supported values of *release* are the current Java SE release and a
 415     limited number of previous releases, detailed in the command-line help.
 416 
 417     If the option is not specified, the default is to compile source code
 418     according to the rules of the Java programming language for the current
 419     Java SE release.
 420 
 421 <a id="option-source-path">`--source-path` *path* or `-sourcepath` *path*</a>
 422 :   Specifies where to find source files.
 423     Except when compiling multiple modules together, this is the source code path
 424     used to search for class or interface definitions.
 425 
 426     **Note:** Classes found through the class path might be recompiled when their source
 427     files are also found. See [Searching for Module, Package and Type Declarations].
 428 
 429 <a id="option-system">`--system` *jdk* \| `none`</a>
 430 :   Overrides the location of system modules.
 431 
 432 <a id="option-target">`--target` *release* or `-target` *release*</a>
 433 :   Generates `class` files suitable for the specified Java SE release.
 434     The supported values of *release* are the current Java SE release and a
 435     limited number of previous releases, detailed in the command-line help.
 436 
 437     **Note:** The target release must be equal to or higher than the source release.
 438     (See [`--source`](#option-source).)
 439 
 440 <a id="option-upgrade-module-path">`--upgrade-module-path` *path*</a>
 441 :   Overrides the location of upgradeable modules.
 442 
 443 <a id="option-verbose">`-verbose`</a>
 444 :   Outputs messages about what the compiler is doing. Messages include
 445     information about each class loaded and each source file compiled.
 446 
 447 <a id="option-version">`--version` or `-version`</a>
 448 :   Prints version information.
 449 
 450 <a id="option-Werror">`-Werror`</a>
 451 :   Terminates compilation when any warnings occur; this includes warnings in all lint
 452     categories, as well as non-lint warnings.
 453 
 454 <a id="option-Werror-custom">`-Werror:`\[`-`\]*key*(`,`\[`-`\]*key*)\*</a>
 455 :   Specify lint categories for which warnings should terminate compilation. The keys
 456     `all` and `none` include or exclude all categories (respectively); other keys include
 457     the corresponding category, or exclude it if preceded by a hyphen (`-`). By default,
 458     no categories are included. In order to terminate compilation, the category must also
 459     be enabled (via [`-Xlint`](#option-Xlint-custom), if necessary).
 460     See [`-Xlint`](#option-Xlint-custom) below for the list of lint category keys.
 461 
 462 ### Extra Options
 463 
 464 <a id="option-add-exports">`--add-exports` *module*`/`*package*`=`*other-module*(`,`*other-module*)\*</a>
 465 :   Specifies a package to be considered as exported from its defining module
 466     to additional modules or to all unnamed modules when the value of
 467     *other-module* is `ALL-UNNAMED`.
 468 
 469 <a id="option-add-reads">`--add-reads` *module*`=`*other-module*(`,`*other-module*)\*</a>
 470 :   Specifies additional modules to be considered as required by a given
 471     module.
 472 
 473 <a id="option-default-module-for-created-files">`--default-module-for-created-files` *module-name*</a>
 474 :   Specifies the fallback target module for files created by annotation
 475     processors, if none is specified or inferred.
 476 
 477 <a id="option-disable-line-doc-comments">`--disable-line-doc-comments`</a>
 478 :   Disables support for documentation comments with lines beginning ///.
 479 
 480 <a id="option-Djava.endorsed.dirs">`-Djava.endorsed.dirs=`*dirs*</a>
 481 :   Overrides the location of the endorsed standards path.
 482 
 483     **Note:** This can only be used when compiling for releases prior to JDK 9.
 484     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 485     or [`-target`](#option-target) for details.
 486 
 487 <a id="option-Djava.ext.dirs">`-Djava.ext.dirs=`*dirs*</a>
 488 :   Overrides the location of installed extensions.
 489 
 490     **Note:** This can only be used when compiling for releases prior to JDK 9.
 491     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 492     or [`-target`](#option-target) for details.
 493 
 494 <a id="option-patch-module">`--patch-module` *module*`=`*path*</a>
 495 :   Overrides or augments a module with classes and resources in JAR files or
 496     directories.
 497 
 498 <a id="option-Xbootclasspath">`-Xbootclasspath:`*path*</a>
 499 :   Overrides the location of the bootstrap class files.
 500 
 501     **Note:** This can only be used when compiling for releases prior to JDK 9.
 502     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 503     or [`-target`](#option-target) for details.
 504 
 505 <a id="option-Xbootclasspath-a">`-Xbootclasspath/a:`*path*</a>
 506 :   Adds a suffix to the bootstrap class path.
 507 
 508     **Note:** This can only be used when compiling for releases prior to JDK 9.
 509     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 510     or [`-target`](#option-target) for details.
 511 
 512 <a id="option-Xbootclasspath-p">`-Xbootclasspath/p:`*path*</a>
 513 :   Adds a prefix to the bootstrap class path.
 514 
 515     **Note:** This can only be used when compiling for releases prior to JDK 9.
 516     As applicable, see the descriptions in [`--release`](#option-release), [`-source`](#option-source),
 517     or [`-target`](#option-target) for details.
 518 
 519 <a id="option-Xdiags">`-Xdiags:`\[`compact`, `verbose`\]</a>
 520 :   Selects a diagnostic mode.
 521 
 522 <a id="option-Xdoclint">`-Xdoclint`</a>
 523 :   Enables recommended checks for problems in documentation comments.
 524 
 525 <a id="option-Xdoclint-custom">`-Xdoclint:`(`all`|`none`|\[`-`\]*group*)\[`/`*access*\]</a>
 526 :   Enables or disables specific groups of checks in documentation comments.
 527 
 528     *group* can have one of the following values:
 529     `accessibility`, `html`, `missing`, `reference`, `syntax`.
 530 
 531     The variable *access* specifies the minimum visibility level of classes and
 532     members that the `-Xdoclint` option checks. It can have one of the
 533     following values (in order of most to least visible):
 534     `public`, `protected`, `package`, `private`.
 535 
 536     The default *access* level is `private`.
 537 
 538     When prefixed by `doclint:`, the *group* names and `all` can be used with `@SuppressWarnings`
 539     to suppress warnings about documentation comments in parts of the code being compiled.
 540 
 541     For more information about these groups of checks, see the [DocLint](javadoc.html#doclint)
 542     section of the `javadoc` command documentation.
 543     The `-Xdoclint` option is disabled by default in the `javac` command.
 544 
 545     For example, the following option checks classes and members (with all
 546     groups of checks) that have the access level of protected and higher (which
 547     includes protected and public):
 548 
 549     >   `-Xdoclint:all/protected`
 550 
 551     The following option enables all groups of checks for all access levels,
 552     except it will not check for HTML errors for classes and members that have the
 553     access level of package and higher (which includes package, protected and
 554     public):
 555 
 556     >   `-Xdoclint:all,-html/package`
 557 
 558 <a id="option-Xdoclint-package">`-Xdoclint/package:`\[`-`\]*packages*(`,`\[`-`\]*package*)\*</a>
 559 :   Enables or disables checks in specific packages. Each *package* is either
 560     the qualified name of a package or a package name prefix followed by `.*`,
 561     which expands to all sub-packages of the given package. Each *package* can
 562     be prefixed with a hyphen (`-`) to disable checks for a specified package
 563     or packages.
 564 
 565     For more information, see the [DocLint](javadoc.html#doclint)
 566     section of the `javadoc` command documentation.
 567 
 568 <a id="option-Xlint">`-Xlint`</a>
 569 :   Enables recommended lint warning categories. In this release, all available
 570     lint warning categories are recommended.
 571 
 572 <a id="option-Xlint-custom">`-Xlint:`\[`-`\]*key*(`,`\[`-`\]*key*)\*</a>
 573 :   Enables and/or disables lint warning categories using the one or more of the keys described
 574     below separated by commas. The keys `all` and `none` enable or disable all categories
 575     (respectively); other keys enable the corresponding category, or disable it if preceded
 576     by a hyphen (`-`).
 577 
 578     Supported values for *key* are:
 579 
 580     -   `all`: Enables all warning categories.
 581 
 582     -   `auxiliaryclass`: Warns about an auxiliary class that is hidden in a
 583         source file, and is used from other files.
 584 
 585     -   `cast`: Warns about the use of unnecessary casts.
 586 
 587     -   `classfile`: Warns about the issues related to classfile contents.
 588 
 589     -   `dangling-doc-comments`: Warns about extra or misplaced documentation
 590          comments near the beginning of a declaration.
 591 
 592     -   `deprecation`: Warns about the use of deprecated items.
 593 
 594     -   `dep-ann`: Warns about the items marked as deprecated in `javadoc` but
 595         without the `@Deprecated` annotation.
 596 
 597     -   `divzero`: Warns about the division by the constant integer 0.
 598 
 599     -   `empty`: Warns about an empty statement after `if`.
 600 
 601     -   `exports`: Warns about the issues regarding module exports.
 602 
 603     -   `fallthrough`: Warns about the falling through from one case of a
 604         switch statement to the next.
 605 
 606     -   `finally`: Warns about `finally` clauses that do not terminate normally.
 607 
 608     -   `identity`: Warns about use of a value-based class where an identity
 609         class is expected
 610 
 611     -   `incubating`: Warns about the use of incubating modules.
 612 
 613     -   `initialization`: Warns about code in identity classes that wouldn't be
 614         allowed in early construction due to a `this` dependency.
 615 
 616     -   `lossy-conversions`: Warns about possible lossy conversions
 617         in compound assignment.
 618 
 619     -   `missing-explicit-ctor`: Warns about missing explicit constructors in
 620          public and protected classes in exported packages.
 621 
 622     -   `module`: Warns about the module system-related issues.
 623 
 624     -   `opens`: Warns about the issues related to module opens.
 625 
 626     -   `options`: Warns about the issues relating to use of command line
 627         options.
 628 
 629     -   `output-file-clash`: Warns if any output file is overwritten during compilation.
 630          This can occur, for example, on case-insensitive filesystems.
 631 
 632     -   `overloads`: Warns about the issues related to method overloads.
 633 
 634     -   `overrides`: Warns about the issues related to method overrides.
 635 
 636     -   `path`: Warns about the invalid path elements on the command line.
 637 
 638     -   `preview`: Warns about the use of preview language features.
 639 
 640     -   `processing`: Warns about the issues related to annotation processing.
 641 
 642     -   `rawtypes`: Warns about the use of raw types.
 643 
 644     -   `removal`: Warns about the use of an API that has been marked for
 645         removal.
 646 
 647     -   `restricted`: Warns about the use of restricted methods.
 648 
 649     -   `requires-automatic`: Warns developers about the use of automatic
 650         modules in requires clauses.
 651 
 652     -   `requires-transitive-automatic`: Warns about automatic modules in
 653         requires transitive.
 654 
 655     -   `serial`: Warns about the serializable classes that do not provide a
 656         serial version ID. Also warns about access to non-public members from a
 657         serializable element.
 658 
 659     -   `static`: Warns about the accessing a static member using an instance.
 660 
 661     -   `strictfp`: Warns about unnecessary use of the `strictfp` modifier.
 662 
 663     -   `synchronization`: Deprecated alias for `identity` with an identical
 664         effect. Users are encouraged to use `identity` instead of `synchronization`
 665         for all current and future uses.
 666 
 667     -   `text-blocks`: Warns about inconsistent white space characters in text
 668         block indentation.
 669 
 670     -  `this-escape`: Warns about constructors leaking `this` prior to subclass initialization.
 671 
 672     -   `try`: Warns about the issues relating to the use of try blocks (that
 673         is, try-with-resources).
 674 
 675     -   `unchecked`: Warns about the unchecked operations.
 676 
 677     -   `varargs`: Warns about the potentially unsafe `vararg` methods.
 678 
 679     -   `none`: Disables all warning categories.
 680 
 681     The keys listed above may be used in `@SuppressWarnings` annotations to suppress
 682     warnings within the annotated declaration, with the exception of: `all`, `none`,
 683     `classfile`, `incubating`, `options`, `output-file-clash`, `processing`, and `path`.
 684 
 685     By default, the following lint warning categories are enabled: `dep-ann`, `identity`,
 686     `incubating`, `module`, `opens`, `preview`, `removal`, `requires-transitive-automatic`,
 687     and `strictfp`.
 688 
 689     See [Examples of Using -Xlint keys].
 690 
 691 <a id="option-Xmaxerrs">`-Xmaxerrs` *number*</a>
 692 :   Sets the maximum number of errors to print.
 693 
 694 <a id="option-Xmaxwarns">`-Xmaxwarns` *number*</a>
 695 :   Sets the maximum number of warnings to print.
 696 
 697 <a id="option-Xpkginfo">`-Xpkginfo:`\[`always`, `legacy`, `nonempty`\]</a>
 698 :   Specifies when and how the `javac` command generates `package-info.class`
 699     files from `package-info.java` files using one of the following options:
 700 
 701     `always`
 702     :   Generates a `package-info.class` file for every `package-info.java`
 703         file. This option may be useful if you use a build system such as Ant,
 704         which checks that each `.java` file has a corresponding `.class` file.
 705 
 706     `legacy`
 707     :   Generates a `package-info.class` file only if `package-info.java`
 708         contains annotations. This option does not generate a
 709         `package-info.class` file if `package-info.java` contains only
 710         comments.
 711 
 712         **Note:** A `package-info.class` file might be generated but be empty if all the
 713         annotations in the `package-info.java` file have
 714         `RetentionPolicy.SOURCE`.
 715 
 716     `nonempty`
 717     :   Generates a `package-info.class` file only if `package-info.java`
 718         contains annotations with `RetentionPolicy.CLASS` or
 719         `RetentionPolicy.RUNTIME`.
 720 
 721 <a id="option-Xplugin">`-Xplugin:`*name* *args*</a>
 722 :   Specifies the name and optional arguments for a plug-in to be run.
 723     If *args* are provided, *name* and *args* should be quoted or otherwise
 724     escape the whitespace characters between the name and all the arguments.
 725     For details on the API for a plugin, see the API documentation for
 726     [jdk.compiler/com.sun.source.util.Plugin](../../api/jdk.compiler/com/sun/source/util/Plugin.html).
 727 
 728 <a id="option-Xprefer">`-Xprefer:`\[`source`, `newer`\]</a>
 729 :   Specifies which file to read when both a source file and class file are
 730     found for an implicitly compiled class using one of the following options.
 731     See [Searching for Module, Package and Type Declarations].
 732 
 733     -   `-Xprefer:newer`: Reads the newer of the source or class files for a
 734         type (default).
 735 
 736     -   `-Xprefer:source` : Reads the source file. Use `-Xprefer:source` when
 737         you want to be sure that any annotation processors can access
 738         annotations declared with a retention policy of `SOURCE`.
 739 
 740 <a id="option-Xprint">`-Xprint`</a>
 741 :   Prints a textual representation of specified types for debugging purposes.
 742     This does not perform annotation processing or compilation. The format of
 743     the output could change.
 744 
 745 <a id="option-XprintProcessorInfo">`-XprintProcessorInfo`</a>
 746 :   Prints information about which annotations a processor is asked to process.
 747 
 748 <a id="option-XprintRounds">`-XprintRounds`</a>
 749 :   Prints information about initial and subsequent annotation processing
 750     rounds.
 751 
 752 <a id="option-Xstdout">`-Xstdout` *filename*</a>
 753 :   Sends compiler messages to the named file. By default, compiler messages go
 754     to `System.err`.
 755 
 756 ## Environment Variables
 757 
 758 ### CLASSPATH
 759 
 760 If the [`--class-path`](#option-class-path) option or any of its alternate forms are not specified,
 761 the class path will default to the value of the `CLASSPATH` environment
 762 variable if it is set.
 763 However, it is recommended that this environment variable should _not_ be set,
 764 and that the `--class-path` option should be used to provide an explicit
 765 value for the class path when one is required.
 766 
 767 ### JDK\_JAVAC\_OPTIONS
 768 
 769 The content of the `JDK_JAVAC_OPTIONS` environment variable, separated by
 770 white-spaces ( ) or white-space characters (`\n`, `\t`, `\r`, or `\f`) is
 771 prepended to the command line arguments passed to `javac` as a list of
 772 arguments.
 773 
 774 The encoding requirement for the environment variable is the same as the
 775 `javac` command line on the system. `JDK_JAVAC_OPTIONS` environment variable
 776 content is treated in the same manner as that specified in the command line.
 777 
 778 Single quotes (`'`) or double quotes (`"`) can be used to enclose arguments
 779 that contain whitespace characters. All content between the open quote and the
 780 first matching close quote are preserved by simply removing the pair of quotes.
 781 In case a matching quote is not found, the launcher will abort with an error
 782 message. `@`*files* are supported as they are specified in the command line.
 783 However, as in `@`*files*, use of a wildcard is not supported.
 784 
 785 **Examples of quoting arguments containing white spaces:**
 786 
 787 >   `export JDK_JAVAC_OPTIONS='@"C:\white spaces\argfile"'`
 788 
 789 >   `export JDK_JAVAC_OPTIONS='"@C:\white spaces\argfile"'`
 790 
 791 >   `export JDK_JAVAC_OPTIONS='@C:\"white spaces"\argfile'`
 792 
 793 ## Command-Line Argument Files
 794 
 795 An argument file can include command-line options and source file names in any
 796 combination. The arguments within a file can be separated by spaces or new line
 797 characters. If a file name contains embedded spaces, then put the whole file
 798 name in double quotation marks.
 799 
 800 File names within an argument file are relative to the current directory, not
 801 to the location of the argument file. Wildcards (`*`) are not allowed in these
 802 lists (such as for specifying `*.java`). Use of the at sign (`@`) to
 803 recursively interpret files is not supported. The `-J` options are not supported
 804 because they're passed to the launcher, which does not support argument files.
 805 
 806 When executing the `javac` command, pass in the path and name of each argument
 807 file with the at sign (`@`) leading character. When the `javac` command
 808 encounters an argument beginning with the at sign (`@`), it expands the
 809 contents of that file into the argument list.
 810 
 811 
 812 ### Examples of Using javac @filename
 813 
 814 Single Argument File
 815 :   You could use a single argument file named `argfile` to hold all `javac`
 816     arguments:
 817 
 818     >   `javac @argfile`
 819 
 820     This argument file could contain the contents of both files shown in the
 821     following **Two Argument Files** example.
 822 
 823 Two Argument Files
 824 :   You can create two argument files: one for the `javac` options and the
 825     other for the source file names. Note that the following lists have no
 826     line-continuation characters.
 827 
 828     Create a file named `options` that contains the following:
 829 
 830     **Linux and macOS:**
 831 
 832     ```
 833     -d classes
 834     -g
 835     -sourcepath /java/pubs/ws/1.3/src/share/classes
 836     ```
 837 
 838     **Windows:**
 839 
 840     ```
 841     -d classes
 842     -g
 843     -sourcepath C:\java\pubs\ws\1.3\src\share\classes
 844     ```
 845 
 846     Create a file named `sources` that contains the following:
 847 
 848     ```
 849     MyClass1.java
 850     MyClass2.java
 851     MyClass3.java
 852     ```
 853 
 854     Then, run the `javac` command as follows:
 855 
 856     >   `javac @options @sources`
 857 
 858 Argument Files with Paths
 859 :   The argument files can have paths, but any file names inside the files are
 860     relative to the current working directory (not `path1` or `path2`):
 861 
 862     >   `javac @path1/options @path2/sources`
 863 
 864 ## Arrangement of Source Code
 865 
 866 In the Java language, classes and interfaces can be organized into
 867 packages, and packages can be organized into modules. `javac` expects
 868 that the physical arrangement of source files in directories of the
 869 file system will mirror the organization of classes into packages, and
 870 packages into modules.
 871 
 872 It is a widely adopted convention that module names and package names
 873 begin with a lower-case letter, and that class names begin with an
 874 upper-case letter.
 875 
 876 ### Arrangement of Source Code for a Package
 877 
 878 When classes and interfaces are organized into a package, the package
 879 is represented as a directory, and any subpackages are represented as
 880 subdirectories.
 881 
 882 For example:
 883 
 884 - The package `p` is represented as a directory called `p`.
 885 
 886 - The package `p.q` -- that is, the subpackage `q` of package `p` --
 887   is represented as the subdirectory `q` of directory `p`. The
 888   directory tree representing package `p.q` is therefore `p\q`
 889   on Windows, and `p/q` on other systems.
 890 
 891 - The package `p.q.r` is represented as the directory tree `p\q\r`
 892   (on Windows) or `p/q/r` (on other systems).
 893 
 894 Within a directory or subdirectory, `.java` files represent classes
 895 and interfaces in the corresponding package or subpackage.
 896 
 897 For example:
 898 
 899 - The class `X` declared in package `p` is represented by the file
 900   `X.java` in the `p` directory.
 901 
 902 - The class `Y` declared in package `p.q` is represented by the file
 903   `Y.java` in the `q` subdirectory of directory `p`.
 904 
 905 - The class `Z` declared in package `p.q.r` is represented by the file
 906   `Z.java` in the `r` subdirectory of `p\q` (on Windows) or `p/q`
 907   (on other systems).
 908 
 909 In some situations, it is convenient to split the code into
 910 separate directories, each structured as described above, and
 911 the aggregate list of directories specified to `javac`.
 912 
 913 ### Arrangement of Source Code for a Module
 914 
 915 In the Java language, a module is a set of packages designed for
 916 reuse. In addition to `.java` files for classes and interfaces, each
 917 module has a source file called `module-info.java` which:
 918 
 919 1. declares the module's name;
 920 
 921 2. lists the packages exported by the module (to allow reuse by other
 922    modules);
 923 
 924 3. lists other modules required by the module (to reuse their exported
 925    packages).
 926 
 927 When packages are organized into a module, the module is represented
 928 by one or more directories representing the packages in the module,
 929 one of which contains the `module-info.java` file. It may be convenient,
 930 but it is not required, to use a single directory, named after the module,
 931 to contain the `module-info.java` file alongside the directory tree which
 932 represents the packages in the module (i.e., the _package hierarchy_
 933 described above). The exact arrangement of source code for a module
 934 is typically dictated by the conventions adopted by a development
 935 environment (IDE) or build system.
 936 
 937 For example:
 938 
 939 - The module `a.b.c` may be represented by the directory `a.b.c`, on all
 940   systems.
 941 
 942 - The module's declaration is represented by the file
 943   `module-info.java` in the `a.b.c` directory.
 944 
 945 - If the module contains package `p.q.r`, then the `a.b.c` directory
 946   contains the directory tree `p\q\r` (on Windows) or `p/q/r`
 947   (on other systems).
 948 
 949 The development environment may prescribe some directory hierarchy
 950 between the directory named for the module and the source files to
 951 be read by `javac`.
 952 
 953 For example:
 954 
 955 - The module `a.b.c` may be represented by the directory `a.b.c`
 956 
 957 - The module's declaration and the module's packages may be in
 958   some subdirectory of `a.b.c`, such as `src\main\java` (on Windows)
 959   or `src/main/java` (on other systems).
 960 
 961 
 962 ## Configuring a Compilation
 963 
 964 This section describes how to configure `javac` to perform a basic compilation.
 965 
 966 See [Configuring the Module System] for additional details for use when compiling
 967 for a release of the platform that supports modules.
 968 
 969 ### Source Files
 970 
 971 *   Specify the source files to be compiled on the command line.
 972 
 973 If there are no compilation errors, the corresponding class files will
 974 be placed in the [output directory].
 975 
 976 Some systems may limit the amount you can put on a command line;
 977 to work around those limits, you can use [argument files](#command-line-argument-files).
 978 
 979 When compiling code for modules, you can also specify source files indirectly,
 980 by using the [`--module`](#option-module) or `-m` option.
 981 
 982 ### Output Directory
 983 
 984 *   Use the [`-d`](#option-d) option to specify an output directory in which to put the compiled class files.
 985 
 986 This will normally be organized in a [package hierarchy](#package-hierarchy),
 987 unless you are compiling source code from multiple modules, in which case it will be
 988 organized as a [module hierarchy](#module-hierarchy).
 989 
 990 When the compilation has been completed, if you are compiling one or more modules,
 991 you can place the output directory on the module path for the Java [launcher](java.html);
 992 otherwise, you can place the place the output directory on the class path
 993 for the Java launcher.
 994 
 995 ### Precompiled Code
 996 
 997 The code to be compiled may refer to libraries beyond what is provided by the platform.
 998 If so, you must place these libraries on the class path or module path.
 999 If the library code is not in a module, place it on the class path;
1000 if it is in a module, place it on the module path.
1001 
1002 *   Use the [`--class-path`](#option-class-path) option to specify libraries to be placed on the class path.
1003     Locations on the class path should be organized in a [package hierarchy](#package-hierarchy).
1004     You can also use alternate forms of the option: `-classpath` or `-cp`.
1005 
1006 *   Use the [`--module-path`](#option-module-path) option to specify libraries to be placed on the module path.
1007     Locations on the module path should either be modules or directories of modules.
1008     You can also use an alternate form of the option: `-p`.
1009 
1010     See [Configuring the Module System] for details on how to modify the default
1011     configuration of library modules.
1012 
1013 **Note**: the options for the class path and module path are not mutually
1014 exclusive, although it is not common to specify the class path when compiling
1015 code for one or more modules.
1016 
1017 ### Additional Source Files
1018 
1019 The code to be compiled may refer to types in additional source files that are not
1020 specified on the command line.
1021 If so, you must put those source files on either the source path or module path.
1022 You can only specify one of these options: if you are not compiling code for a module,
1023 or if you are only compiling code for a single module, use the source path;
1024 if you are compiling code for multiple modules, use the module source path.
1025 
1026 *   Use the [`--source-path`](#option-source-path) option to specify the locations of additional source
1027     files that may be read by javac.
1028     Locations on the source path should be organized in a [package hierarchy](#package-hierarchy).
1029     You can also use an alternate form of the option: `-sourcepath`.
1030 
1031 *   Use the [`--module-source-path`](#option-module-source-path) option one or more times to specify the location
1032     of additional source files in different modules that may be read by javac,
1033     or when compiling source files in multiple modules.
1034     You can either specify the locations for each module [individually](#module-specific-form),
1035     or you can organize the source files so that you can specify the locations all
1036     [together](#module-pattern-form).  For more details, see [The Module Source Path Option].
1037 
1038 If you want to be able to refer to types in additional source files but do not
1039 want them to be compiled, use the [`-implicit`](#option-implicit) option.
1040 
1041 **Note**: if you are compiling code for multiple modules, you must always specify
1042 a module source path, and all source files specified on the command line must be
1043 in one of the directories on the module source path, or in a subdirectory thereof.
1044 
1045 
1046 ### Example of Compiling Multiple Source Files
1047 
1048 This example compiles the `Aloha.java`, `GutenTag.java`, `Hello.java`, and
1049 `Hi.java` source files in the `greetings` package.
1050 
1051 **Linux and macOS:**
1052 
1053 ```
1054 % javac greetings/*.java
1055 % ls greetings
1056 Aloha.class         GutenTag.class      Hello.class         Hi.class
1057 Aloha.java          GutenTag.java       Hello.java          Hi.java
1058 ```
1059 
1060 **Windows:**
1061 
1062 ```
1063 C:\>javac greetings\*.java
1064 C:\>dir greetings
1065 Aloha.class         GutenTag.class      Hello.class         Hi.class
1066 Aloha.java          GutenTag.java       Hello.java          Hi.java
1067 ```
1068 
1069 ### Example of Specifying a User Class Path
1070 
1071 After changing one of the source files in the previous example, recompile it:
1072 
1073 **Linux and macOS:**
1074 
1075 ```
1076 pwd
1077 /examples
1078 javac greetings/Hi.java
1079 ```
1080 
1081 **Windows:**
1082 
1083 ```
1084 C:\>cd
1085 \examples
1086 C:\>javac greetings\Hi.java
1087 ```
1088 
1089 Because `greetings.Hi` refers to other classes in the `greetings` package, the
1090 compiler needs to find these other classes. The previous example works because
1091 the default user class path is the directory that contains the package
1092 directory. If you want to recompile this file without concern for which
1093 directory you are in, then add the examples directory to the user class path by
1094 setting `CLASSPATH`. This example uses the `-classpath` option.
1095 
1096 **Linux and macOS:**
1097 
1098 >   `javac -classpath /examples /examples/greetings/Hi.java`
1099 
1100 **Windows:**
1101 
1102 >   `C:\>javac -classpath \examples \examples\greetings\Hi.java`
1103 
1104 If you change `greetings.Hi` to use a banner utility, then that utility also
1105 needs to be accessible through the user class path.
1106 
1107 **Linux and macOS:**
1108 
1109 ```
1110 javac -classpath /examples:/lib/Banners.jar \
1111             /examples/greetings/Hi.java
1112 ```
1113 
1114 **Windows:**
1115 
1116 ```
1117 C:\>javac -classpath \examples;\lib\Banners.jar ^
1118             \examples\greetings\Hi.java
1119 ```
1120 
1121 To execute a class in the `greetings` package, the program needs access to the
1122 `greetings` package, and to the classes that the `greetings` classes use.
1123 
1124 **Linux and macOS:**
1125 
1126 >   `java -classpath /examples:/lib/Banners.jar greetings.Hi`
1127 
1128 **Windows:**
1129 
1130 >   `C:\>java -classpath \examples;\lib\Banners.jar greetings.Hi`
1131 
1132 ## Configuring the Module System
1133 
1134 If you want to include additional modules in your compilation, use the
1135 [`--add-modules`](#option-add-modules) option.
1136 This may be necessary when you are compiling code that is not in a module,
1137 or which is in an automatic module, and the code refers to API in the additional
1138 modules.
1139 
1140 If you want to restrict the set of modules in your compilation, use the
1141 [`--limit-modules`](#option-limit-modules) option.
1142 This may be useful if you want to ensure that the code you are compiling
1143 is capable of running on a system with a limited set of modules installed.
1144 
1145 If you want to break encapsulation and specify that additional packages
1146 should be considered as exported from a module, use the [`--add-exports`](#option-add-exports) option.
1147 This may be useful when performing white-box testing; relying on access
1148 to internal API in production code is strongly discouraged.
1149 
1150 If you want to specify that additional packages
1151 should be considered as required by a module, use the [`--add-reads`](#option-add-reads) option.
1152 This may be useful when performing white-box testing; relying on access
1153 to internal API in production code is strongly discouraged.
1154 
1155 You can patch additional content into any module using the
1156 [`--patch-module`](#option-patch-module) option. See [Patching a Module] for more details.
1157 
1158 ## Searching for Module, Package and Type Declarations
1159 
1160 To compile a source file, the compiler often needs information about a module
1161 or type, but the declaration is not in the source files specified on the command
1162 line.
1163 
1164 `javac` needs type information for every class or interface used,
1165 extended, or implemented in the source file. This includes classes and
1166 interfaces not explicitly mentioned in the source file, but that provide
1167 information through inheritance.
1168 
1169 For example, when you create a subclass of `java.awt.Window`, you are also
1170 using the ancestor classes of `Window`: `java.awt.Container`,
1171 `java.awt.Component`, and `java.lang.Object`.
1172 
1173 When compiling code for a module, the compiler also needs to have available
1174 the declaration of that module.
1175 
1176 A successful search may produce a class file, a source file, or both. If
1177 both are found, then you can use the [`-Xprefer`](#option-Xprefer) option to instruct the compiler
1178 which to use.
1179 
1180 If a search finds and uses a source file, then by default `javac`
1181 compiles that source file. This behavior can be altered with
1182 [`-implicit`](#option-implicit).
1183 
1184 The compiler might not discover the need for some type information until after
1185 annotation processing completes. When the type information is found in a source
1186 file and no [`-implicit`](#option-implicit) option is specified, the compiler gives a warning that
1187 the file is being compiled without being subject to annotation processing. To
1188 disable the warning, either specify the file on the command line (so that it
1189 will be subject to annotation processing) or use the [`-implicit`](#option-implicit) option to
1190 specify whether or not class files should be generated for such source files.
1191 
1192 The way that `javac` locates the declarations of those types
1193 depends on whether the reference exists within code for a module or not.
1194 
1195 ### Searching Package Oriented Paths
1196 
1197 When searching for a source or class file on a path composed of package oriented
1198 locations, `javac` will check each location on the path in turn for the
1199 possible presence of the file. The first occurrence of a particular file
1200 shadows (hides) any subsequent occurrences of like-named files. This shadowing
1201 does not affect any search for any files with a different name. This can be
1202 convenient when searching for source files, which may be grouped in different
1203 locations, such as shared code, platform-specific code and generated code.
1204 It can also be useful when injecting alternate versions of a class file into
1205 a package, to debugging or other instrumentation reasons. But, it can also
1206 be dangerous, such as when putting incompatible different versions of a library
1207 on the class path.
1208 
1209 ### Searching Module Oriented Paths
1210 
1211 Prior to scanning any module paths for any package or type declarations,
1212 `javac` will lazily scan the following paths and locations to determine
1213 the modules that will be used in the compilation.
1214 
1215 * The module source path (see the [`--module-source-path`](#option-module-source-path) option)
1216 * The path for upgradeable modules (see the [`--upgrade-module-path`](#option-upgrade-module-path) option)
1217 * The system modules (see the [`--system`](#option-system) option)
1218 * The user module path ( see the [`--module-path`](#option-module-path) option)
1219 
1220 For any module, the first occurrence of the module during the scan completely
1221 shadows (hides) any subsequent appearance of a like-named module. While locating
1222 the modules, `javac` is able to determine the packages exported by the module
1223 and to associate with each module a package oriented path for the contents of
1224 the module. For any previously compiled module, this path will typically be a
1225 single entry for either a directory or a file that provides an internal
1226 directory-like hierarchy, such as a JAR file. Thus, when searching for a type
1227 that is in a package that is known to be exported by a module, `javac` can
1228 locate the declaration directly and efficiently.
1229 
1230 ### Searching for the Declaration of a Module
1231 
1232 If the module has been previously compiled, the module declaration is
1233 located in a file named `module-info.class` in the root of the package hierarchy
1234 for the content of the module.
1235 
1236 If the module is one of those currently being compiled, the module declaration
1237 will be either the file named `module-info.class` in the root of the
1238 package hierarchy for the module in the class output directory, or the
1239 file named `module-info.java` in one of the locations on the source path
1240 or one the module source path for the module.
1241 
1242 ### Searching for the Declaration of a Type When the Reference is not in a Module
1243 
1244 When searching for a type that is referenced in code that is not in a module,
1245 `javac` will look in the following places:
1246 
1247 *   The platform classes (or the types in exported packages of the platform modules)
1248     (This is for compiled class files only.)
1249 
1250 *   Types in exported packages of any modules on the module path, if applicable.
1251     (This is for compiled class files only.)
1252 
1253 *   Types in packages on the class path and/or source path:
1254 
1255     *   If both are specified, `javac` looks for compiled class files on the class path
1256         and for source files on the source path.
1257 
1258     *   If the class path is specified, but not source path, `javac` looks for both
1259         compiled class files and source files on the class path.
1260 
1261     *   If the class path is not specified, it defaults to the current directory.
1262 
1263 When looking for a type on the class path and/or source path, if both a compiled
1264 class file and a source file are found, the most recently modified file will
1265 be used by default.
1266 If the source file is newer, it will be compiled and will may override any
1267 previously compiled version of the file.  You can use the [`-Xprefer`](#option-Xprefer) option
1268 to override the default behavior.
1269 
1270 ### Searching for the Declaration of a Type When the Reference is in a Module
1271 
1272 When searching for a type that is referenced in code in a module,
1273 `javac` will examine the declaration of the enclosing module to determine
1274 if the type is in a package that is exported from another module that is
1275 readable by the enclosing module.
1276 If so, `javac` will simply and directly go to the definition of that module
1277 to find the definition of the required type.
1278 Unless the module is another of the modules being compiled, `javac` will
1279 only look for compiled class files files. In other words, `javac` will
1280 not look for source files in platform modules or modules on the module path.
1281 
1282 If the type being referenced is not in some other readable module,
1283 `javac` will examine the module being compiled to try and find the
1284 declaration of the type.
1285 `javac` will look for the declaration of the type as follows:
1286 
1287 *   Source files specified on the command line or on the source path or
1288     module source path.
1289 
1290 *   Previously compiled files in the output directory.
1291 
1292 
1293 ## Directory Hierarchies
1294 
1295 `javac` generally assumes that source files and compiled class files will be
1296 organized in a file system directory hierarchy or in a type of file that
1297 supports in an internal directory hierarchy, such as a JAR file.
1298 Three different kinds of hierarchy are supported: a _package hierarchy_,
1299 a _module hierarchy_, and a _module source hierarchy_.
1300 
1301 While `javac` is fairly relaxed about the organization of source code,
1302 beyond the expectation that source will be organized in one or package
1303 hierarchies, and can generally accommodate organizations prescribed by
1304 development environments and build tools, Java tools in general,
1305 and `javac` and the Java launcher in particular, are more stringent
1306 regarding the organization of compiled class files, and will be
1307 organized in package hierarchies or module hierarchies, as appropriate.
1308 
1309 The location of these hierarchies are specified to `javac` with command-line
1310 options, whose names typically end in "path", like [`--source-path`](#option-source-path) or
1311 [`--class-path`](#option-class-path). Also as a general rule, path options whose name includes the
1312 word `module`, like [`--module-path`](#option-module-path), are used to specify module hierarchies,
1313 although some module-related path options allow a package hierarchy to be
1314 specified on a per-module basis. All other path options are used to specify
1315 package hierarchies.
1316 
1317 ### Package Hierarchy
1318 
1319 In a package hierarchy, directories and subdirectories are used
1320 to represent the component parts of the package name, with the source
1321 file or compiled class file for a type being stored as a file with an
1322 extension of `.java` or `.class` in the most nested directory.
1323 
1324 For example, in a package hierarchy, the source file for a class
1325 `com.example.MyClass` will be stored in the file _com/example/MyClass.java_
1326 
1327 ### Module Hierarchy
1328 
1329 In a module hierarchy, the first level of directories are named
1330 for the modules in the hierarchy; within each of those directories
1331 the contents of the module are organized in package hierarchies.
1332 
1333 For example, in a module hierarchy, the compiled class file for a type called
1334 `com.example.MyClass` in a module called `my.library` will be stored in
1335 _my.library/com/example/MyClass.class_.
1336 
1337 The various output directories used by `javac` (the class output directory,
1338 the source output directory, and native header output directory)
1339 will all be organized in a module hierarchy when multiple modules are being compiled.
1340 
1341 ### Module Source Hierarchy
1342 
1343 Although the source for each individual module should always be
1344 organized in a package hierarchy, it may be convenient to group
1345 those hierarchies into a module source hierarchy. This is similar
1346 to a module hierarchy, except that there may be intervening directories
1347 between the directory for the module and the directory that is
1348 the root of the package hierarchy for the source code of the module.
1349 
1350 For example, in a module source hierarchy, the source file for a type called
1351 `com.example.MyClass` in a module called `my.library` may be stored in a
1352 file such as
1353 _my.library/src/main/java/com/example/MyClass.java_.
1354 
1355 ## The Module Source Path Option
1356 
1357 The [`--module-source-path`](#option-module-source-path) option has two forms: a _module-specific form_,
1358 in which a package path is given for each module containing code to be compiled,
1359 and a _module-pattern_ form, in which the source path for each module is specified
1360 by a pattern.
1361 The module-specific form is generally simpler to use when only a small number of
1362 modules are involved; the module-pattern form may be more convenient when the
1363 number of modules is large and the modules are organized in a regular manner that
1364 can be described by a pattern.
1365 
1366 Multiple instances of the `--module-source-path` option may be given, each one
1367 using either the module-pattern form or the module-specific form, subject to the
1368 following limitations:
1369 
1370 *   the module-pattern form may be used at most once
1371 *   the module-specific form may be used at most once for any given module
1372 
1373 If the module-specific form is used for any module, the associated search path
1374 overrides any path that might otherwise have been inferred from the module-pattern form.
1375 
1376 ### Module-specific form
1377 
1378 The module-specific form allows an explicit search path to be given for any specific module.
1379 This form is:
1380 
1381 *    `--module-source-path` *module-name*`=`*file-path* (*path-separator* *file-path*)*
1382 
1383 The path separator character is `;` on Windows, and `:` otherwise.
1384 
1385 **Note:** this is similar to the form used for the [`--patch-module`](#option-patch-module) option.
1386 
1387 ### Module-pattern form
1388 
1389 The module-pattern form allows a concise specification of the module source path
1390 for any number of modules organized in regular manner.
1391 
1392 *    `--module-source-path` *pattern*
1393 
1394 The pattern is defined by the following rules, which are applied in order:
1395 
1396 *   The argument is considered to be a series of segments separated by the path
1397     separator character (`;` on Windows, and `:` otherwise).
1398 
1399 *   Each segment containing curly braces of the form
1400 
1401         string1{alt1 ( ,alt2 )* } string2
1402 
1403     is considered to be replaced by a series of segments formed by "expanding" the braces:
1404 
1405         string1 alt1 string2
1406         string1 alt2 string2
1407         and so on...
1408 
1409     The braces may be nested.
1410 
1411     This rule is applied for all such usages of braces.
1412 
1413  *  Each segment must have at most one asterisk (`*`).
1414     If a segment does not contain an asterisk, it is considered to be as though the
1415     file separator character and an asterisk are appended.
1416 
1417     For any module _M_, the source path for that module is formed from the series
1418     of segments obtained by substituting the module name _M_ for the asterisk in
1419     each segment.
1420 
1421     **Note**: in this context, the asterisk is just used as a special marker, to
1422     denote the position in the path of the module name. It should not be confused
1423     with the use of `*` as a file name wildcard character, as found on most
1424     operating systems.
1425 
1426 ## Patching Modules
1427 
1428 javac allows any content, whether in source or compiled form, to be patched
1429 into any module using the [`--patch-module`](#option-patch-module) option.
1430 You may want to do this to compile alternative implementations of a class
1431 to be patched at runtime into a JVM, or to inject additional classes into
1432 the module, such as when testing.
1433 
1434 The form of the option is:
1435 
1436 *    `--patch-module` *module-name*`=`*file-path* (*path-separator* *file-path* )*
1437 
1438 The path separator character is `;` on Windows, and `:` otherwise.
1439 The paths given for the module must specify the root of a
1440 package hierarchy for the contents of the module
1441 
1442 The option may be given at most once for any given module.
1443 Any content on the path will hide any like-named content later in the path
1444 and in the patched module.
1445 
1446 When patching source code into more than one module, the [`--module-source-path`](#option-module-source-path)
1447 must also be used, so that the output directory is organized in a module hierarchy,
1448 and capable of holding the compiled class files for the modules being compiled.
1449 
1450 ## Annotation Processing
1451 
1452 The `javac` command provides direct support for annotation processing.
1453 
1454 The API for annotation processors is defined in the
1455 `javax.annotation.processing` and `javax.lang.model` packages and subpackages.
1456 
1457 ### How Annotation Processing Works
1458 
1459 Annotation processing is requested by using an option to configure
1460 annotation processing, such as [`-processor`](#option-processor),
1461 [`--processor-path`](#option-processor-path),
1462 [`--processor-module-path`](#option-processor-module-path) or by
1463 explicitly enabling processing with the [`-proc:full`](#option-proc)
1464 or [`-proc:only`](#option-proc) options.  Annotation processing is
1465 disabled using the [`-proc:none`](#option-proc) option.
1466 
1467 If annotation processing is requested, the compiler searches for any
1468 annotation processors that are available.
1469 
1470 The search path can be specified with the
1471 [`-processorpath`](#option-processor-path) option. If no path is
1472 specified, then the user class path is used. Processors are located by
1473 means of service provider-configuration files named
1474 `META-INF/services/javax.annotation.processing.Processor` on the
1475 search path.  Such files should contain the names of any
1476 annotationation processors to be used, listed one per
1477 line. Alternatively, processors can be specified explicitly, using the
1478 [`-processor`](#option-processor) option.
1479 
1480 After scanning the source files and classes on the command line to determine
1481 what annotations are present, the compiler queries the processors to determine
1482 what annotations they process. When a match is found, the processor is called.
1483 A processor can claim the annotations it processes, in which case no further
1484 attempt is made to find any processors for those annotations. After all of the
1485 annotations are claimed, the compiler does not search for additional
1486 processors.
1487 
1488 If any processors generate new source files, then another round of annotation
1489 processing occurs: Any newly generated source files are scanned, and the
1490 annotations processed as before. Any processors called on previous rounds are
1491 also called on all subsequent rounds. This continues until no new source files
1492 are generated.
1493 
1494 After a round occurs where no new source files are generated, the annotation
1495 processors are called one last time, to give them a chance to complete any
1496 remaining work. Finally, unless the [`-proc:only`](#option-proc) option is used, the compiler
1497 compiles the original and all generated source files.
1498 
1499 If you use an annotation processor that generates additional source
1500 files to be included in the compilation, you can specify a default
1501 module to be used for the newly generated files, for use when a
1502 module declaration is not also generated. In this case, use the
1503 [`--default-module-for-created-files`](#option-default-module-for-created-files) option.
1504 
1505 ### Compilation Environment and Runtime Environment.
1506 
1507 The declarations in source files and previously compiled class files are analyzed
1508 by `javac` in a _compilation environment_ that is distinct from the
1509 _runtime environment_ used to execute `javac` itself. Although there is a
1510 deliberate similarity between many `javac` options and like-named options for the
1511 Java [launcher](java.html), such as `--class-path`, `--module-path` and so
1512 on, it is important to understand that in general the `javac` options just affect
1513 the environment in which the source files are compiled, and do not affect
1514 the operation of `javac` itself.
1515 
1516 The distinction between the compilation environment and runtime environment
1517 is significant when it comes to using annotation processors.
1518 Although annotations processors process elements (declarations) that exist
1519 in the compilation environment, the annotation processor itself is executed
1520 in the runtime environment. If an annotation processor has dependencies on
1521 libraries that are not in modules, the libraries can be placed, along with the
1522 annotation processor itself, on the processor path.
1523 (See the [`--processor-path`](#option-processor-path) option.)
1524 If the annotation processor and its dependencies are in modules, you should
1525 use the processor module path instead.
1526 (See the [`--processor-module-path`](#option-processor-module-path) option.)
1527 When those are insufficient, it may be necessary to provide further
1528 configuration of the runtime environment. This can be done in two ways:
1529 
1530 1.  If `javac` is invoked from the command line, options can be passed to the
1531     underlying runtime by prefixing the option with [`-J`](#option-J).
1532 
1533 2.  You can start an instance of a Java Virtual Machine directly and use
1534     command line options and API to configure an environment in which
1535    `javac` can be invoked via one of its [APIs].
1536 
1537 ## Compiling for Earlier Releases of the Platform
1538 
1539 `javac` can compile code that is to be used on other releases of the platform,
1540 using either the [`--release`](#option-release) option, or the [`--source`](#option-source)/`-source` and
1541 [`--target`](#option-target)/`-target` options, together with additional options to specify the
1542 platform classes.
1543 
1544 Depending on the desired platform release, there are some restrictions on some
1545 of the options that can be used.
1546 
1547 *   When compiling for JDK 8 and earlier releases, you cannot use any option
1548     that is intended for use with the module system.
1549     This includes all of the following options:
1550 
1551     *   [`--module-source-path`](#option-module-source-path),
1552         [`--upgrade-module-path`](#option-upgrade-module-path),
1553         [`--system`](#option-system),
1554         [`--module-path`](#option-module-path),
1555         [`--add-modules`](#option-add-modules),
1556         [`--add-exports`](#option-add-exports),
1557         `--add-opens`,
1558         [`--add-reads`](#option-add-reads),
1559         [`--limit-modules`](#option-limit-modules),
1560         [`--patch-module`](#option-patch-module)
1561 
1562     If you use the `--source`/`-source` or `--target`/`-target` options,
1563     you should also set the appropriate platform classes using the
1564     boot class path family of options.
1565 
1566 *   When compiling for JDK 9 and later releases, you cannot use any option
1567     that is intended to configure the boot class path.
1568     This includes all of the following options:
1569 
1570     *    [`-Xbootclasspath/p:`](#option-Xbootclasspath-p),
1571          [`-Xbootclasspath`](#option-Xbootclasspath),
1572          [`-Xbootclasspath/a:`](#option-Xbootclasspath-a),
1573          [`-endorseddirs`](#option-endorseddirs),
1574          [`-Djava.endorsed.dirs`](#option-Djava.endorsed.dirs),
1575          [`-extdirs`](#option-extdirs),
1576          [`-Djava.ext.dirs`](#option-Djava.ext.dirs),
1577          [`-profile`](#option-profile)
1578 
1579     If you use the `--source`/`-source` or `--target`/`-target` options,
1580     you should also set the  appropriate platform classes using the `--system`
1581     option to give the location of an appropriate installed release of JDK.
1582 
1583 When using the `--release` option, only the supported documented API for that
1584 release may be used; you cannot use any options to break encapsulation to
1585 access any internal classes.
1586 
1587 ## APIs
1588 
1589 The `javac` compiler can be invoked using an API in three different ways:
1590 
1591 The [Java Compiler API](../../api/java.compiler/javax/tools/JavaCompiler.html)
1592 :   This provides the most flexible way to invoke the compiler,
1593     including the ability to compile source files provided in
1594     memory buffers or other non-standard file systems.
1595 
1596 The [ToolProvider API](../../api/java.base/java/util/spi/ToolProvider.html)
1597 :   A `ToolProvider` for `javac` can be obtained by calling
1598     `ToolProvider.findFirst("javac")`. This returns an object
1599     with the equivalent functionality of the command-line tool.
1600 
1601     **Note**: This API should not be confused with the like-named
1602     API in the [`javax.tools`](../../api/java.compiler/javax/tools/ToolProvider.html)
1603     package.
1604 
1605 The `javac` [Legacy API](../../api/jdk.compiler/com/sun/tools/javac/Main.html)
1606 :   This API is  retained for backward compatibility only.
1607     All new code should use either the Java Compiler API or the ToolProvider API.
1608 
1609 **Note:** All other classes and methods found in a package with names that start with
1610 `com.sun.tools.javac` (subpackages of `com.sun.tools.javac`) are strictly
1611 internal and subject to change at any time.
1612 
1613 ## Examples of Using -Xlint keys
1614 
1615 `cast`
1616 :   Warns about unnecessary and redundant casts, for example:
1617 
1618     >   `String s = (String) "Hello!"`
1619 
1620 `classfile`
1621 :   Warns about issues related to class file contents.
1622 
1623 `deprecation`
1624 :   Warns about the use of deprecated items. For example:
1625 
1626     ```
1627     java.util.Date myDate = new java.util.Date();
1628     int currentDay = myDate.getDay();
1629     ```
1630 
1631     The method `java.util.Date.getDay` has been deprecated since JDK 1.1.
1632 
1633 `dep-ann`
1634 :   Warns about items that are documented with the `@deprecated` Javadoc
1635     comment, but do not have the `@Deprecated` annotation, for example:
1636 
1637     ```
1638     /**
1639       * @deprecated As of Java SE 7, replaced by {@link #newMethod()}
1640       */
1641     public static void deprecatedMethod() { }
1642     public static void newMethod() { }
1643     ```
1644 
1645 `divzero`
1646 :   Warns about division by the constant integer 0, for example:
1647 
1648     >   `int divideByZero = 42 / 0;`
1649 
1650 `empty`
1651 :   Warns about empty statements after `if`statements, for example:
1652 
1653     ```
1654     class E {
1655         void m() {
1656              if (true) ;
1657         }
1658     }
1659     ```
1660 
1661 `fallthrough`
1662 :   Checks the switch blocks for fall-through cases and provides a warning
1663     message for any that are found. Fall-through cases are cases in a switch
1664     block, other than the last case in the block, whose code does not include a
1665     `break` statement, allowing code execution to fall through from that case to
1666     the next case. For example, the code following the case 1 label in this
1667     switch block does not end with a `break` statement:
1668 
1669     ```
1670     switch (x) {
1671     case 1:
1672       System.out.println("1");
1673       // No break statement here.
1674     case 2:
1675       System.out.println("2");
1676     }
1677     ```
1678 
1679     If the `-Xlint:fallthrough` option was used when compiling this code, then
1680     the compiler emits a warning about possible fall-through into case, with
1681     the line number of the case in question.
1682 
1683 `finally`
1684 :   Warns about `finally` clauses that cannot be completed normally, for
1685     example:
1686 
1687     ```
1688     public static int m() {
1689       try {
1690          throw new NullPointerException();
1691       }  catch (NullPointerException e) {
1692          System.err.println("Caught NullPointerException.");
1693          return 1;
1694        } finally {
1695          return 0;
1696        }
1697       }
1698     ```
1699 
1700     The compiler generates a warning for the `finally` block in this example.
1701     When the `int` method is called, it returns a value of 0. A `finally` block
1702     executes when the `try` block exits. In this example, when control is
1703     transferred to the `catch` block, the `int` method exits. However, the
1704     `finally` block must execute, so it's executed, even though control was
1705     transferred outside the method.
1706 
1707 `options`
1708 :   Warns about issues that related to the use of command-line options. See
1709     [Compiling for Earlier Releases of the Platform].
1710 
1711 `overrides`
1712 :   Warns about issues related to method overrides. For example, consider the
1713     following two classes:
1714 
1715     ```
1716     public class ClassWithVarargsMethod {
1717       void varargsMethod(String... s) { }
1718     }
1719 
1720     public class ClassWithOverridingMethod extends ClassWithVarargsMethod {
1721        @Override
1722        void varargsMethod(String[] s) { }
1723     }
1724     ```
1725 
1726     The compiler generates a warning similar to the following:.
1727 
1728     ```
1729     warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod
1730     overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding
1731     method is missing '...'
1732     ```
1733 
1734     When the compiler encounters a `varargs` method, it translates the
1735     `varargs` formal parameter into an array. In the method
1736     `ClassWithVarargsMethod.varargsMethod`, the compiler translates the
1737     `varargs` formal parameter `String... s` to the formal parameter
1738     `String[] s`, an array that matches the formal parameter of the method
1739     `ClassWithOverridingMethod.varargsMethod`. Consequently, this example
1740     compiles.
1741 
1742 `path`
1743 :   Warns about invalid path elements and nonexistent path directories on the
1744     command line (with regard to the class path, the source path, and other
1745     paths). Such warnings cannot be suppressed with the `@SuppressWarnings`
1746     annotation. For example:
1747 
1748     -   **Linux and macOS:**
1749         `javac -Xlint:path -classpath /nonexistentpath Example.java`
1750 
1751     -   **Windows:**
1752         `javac -Xlint:path -classpath C:\nonexistentpath Example.java`
1753 
1754 `processing`
1755 :   Warns about issues related to annotation processing. The compiler generates
1756     this warning when you have a class that has an annotation, and you use an
1757     annotation processor that cannot handle that type of annotation. For example,
1758     the following is a simple annotation processor:
1759 
1760     **Source file AnnoProc.java**:
1761 
1762     ```
1763     import java.util.*;
1764     import javax.annotation.processing.*;
1765     import javax.lang.model.*;
1766     import javax.lang.model.element.*;
1767 
1768     @SupportedAnnotationTypes("NotAnno")
1769     public class AnnoProc extends AbstractProcessor {
1770       public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv){
1771          return true;
1772       }
1773 
1774       public SourceVersion getSupportedSourceVersion() {
1775          return SourceVersion.latest();
1776        }
1777     }
1778     ```
1779 
1780     **Source file AnnosWithoutProcessors.java**:
1781 
1782     ```
1783     @interface Anno { }
1784 
1785     @Anno
1786     class AnnosWithoutProcessors { }
1787     ```
1788 
1789     The following commands compile the annotation processor `AnnoProc`, then
1790     run this annotation processor against the source file
1791     `AnnosWithoutProcessors.java`:
1792 
1793     ```
1794     javac AnnoProc.java
1795     javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java
1796     ```
1797 
1798     When the compiler runs the annotation processor against the source file
1799     `AnnosWithoutProcessors.java`, it generates the following warning:
1800 
1801     ```
1802     warning: [processing] No processor claimed any of these annotations: Anno
1803     ```
1804 
1805     To resolve this issue, you can rename the annotation defined and used in
1806     the class `AnnosWithoutProcessors` from `Anno` to `NotAnno`.
1807 
1808 `rawtypes`
1809 :   Warns about unchecked operations on raw types. The following statement
1810     generates a `rawtypes` warning:
1811 
1812     >   `void countElements(List l) { ... }`
1813 
1814     The following example does not generate a `rawtypes` warning:
1815 
1816     >   `void countElements(List<?> l) { ... }`
1817 
1818     `List` is a raw type. However, `List<?>` is an unbounded wildcard
1819     parameterized type. Because `List` is a parameterized interface, always
1820     specify its type argument. In this example, the `List` formal argument is
1821     specified with an unbounded wildcard (`?`) as its formal type parameter,
1822     which means that the `countElements` method can accept any instantiation of
1823     the `List` interface.
1824 
1825 `serial`
1826 :   Warns about missing `serialVersionUID` definitions on serializable classes.
1827     For example:
1828 
1829     ```
1830     public class PersistentTime implements Serializable
1831     {
1832       private Date time;
1833 
1834        public PersistentTime() {
1835          time = Calendar.getInstance().getTime();
1836        }
1837 
1838        public Date getTime() {
1839          return time;
1840        }
1841     }
1842     ```
1843 
1844     The compiler generates the following warning:
1845 
1846     ```
1847     warning: [serial] serializable class PersistentTime has no definition of
1848     serialVersionUID
1849     ```
1850 
1851     If a serializable class does not explicitly declare a field named
1852     `serialVersionUID`, then the serialization runtime environment calculates a
1853     default `serialVersionUID` value for that class based on various aspects of
1854     the class, as described in the Java Object Serialization Specification.
1855     However, it's strongly recommended that all serializable classes explicitly
1856     declare `serialVersionUID` values because the default process of computing
1857     `serialVersionUID` values is highly sensitive to class details that can
1858     vary depending on compiler implementations. As a result, this might cause
1859     an unexpected `InvalidClassExceptions` during deserialization. To guarantee
1860     a consistent `serialVersionUID` value across different Java compiler
1861     implementations, a serializable class must declare an explicit
1862     `serialVersionUID` value.
1863 
1864 `static`
1865 :   Warns about issues relating to the use of static variables, for example:
1866 
1867     ```
1868     class XLintStatic {
1869         static void m1() { }
1870         void m2() { this.m1(); }
1871     }
1872     ```
1873 
1874     The compiler generates the following warning:
1875 
1876     ```
1877     warning: [static] static method should be qualified by type name,
1878     XLintStatic, instead of by an expression
1879     ```
1880 
1881     To resolve this issue, you can call the `static` method `m1` as follows:
1882 
1883     >   `XLintStatic.m1();`
1884 
1885     Alternately, you can remove the `static` keyword from the declaration of
1886     the method `m1`.
1887 
1888 `this-escape`
1889 :   Warns about constructors leaking
1890     `this` prior to subclass initialization.
1891     For example, this class:
1892 
1893     ```
1894     public class MyClass {
1895       public MyClass() {
1896         System.out.println(this.hashCode());
1897       }
1898     }
1899     ```
1900 
1901     generates the following warning:
1902 
1903     ```
1904     MyClass.java:3: warning: [this-escape] possible 'this' escape
1905                              before subclass is fully initialized
1906         System.out.println(this.hashCode());
1907                                         ^
1908     ```
1909 
1910     A 'this' escape warning is generated when a constructor does something
1911     that might result in a subclass method being invoked before the
1912     constructor returns.
1913     In such cases the subclass method would be operating on an incompletely
1914     initialized instance.
1915     In the above example, a subclass of `MyClass` that overrides
1916     `hashCode()` to incorporate its own fields would likely produce
1917     an incorrect result when invoked as shown.
1918 
1919     Warnings are only generated if a subclass could exist that is outside
1920     of the current module (or package, if no module) being compiled.
1921     So, for example, constructors in final and non-public classes do not
1922     generate warnings.
1923 
1924 `try`
1925 :   Warns about issues relating to the use of `try` blocks, including
1926     try-with-resources statements. For example, a warning is generated for the
1927     following statement because the resource `ac` declared in the `try` block
1928     is not used:
1929 
1930     ```
1931     try ( AutoCloseable ac = getResource() ) {    // do nothing}
1932     ```
1933 
1934 `unchecked`
1935 :   Gives more detail for unchecked conversion warnings that are mandated by
1936     the Java Language Specification, for example:
1937 
1938     ```
1939     List l = new ArrayList<Number>();
1940     List<String> ls = l;       // unchecked warning
1941     ```
1942 
1943     During type erasure, the types `ArrayList<Number>` and `List<String>`
1944     become `ArrayList` and `List`, respectively.
1945 
1946     The `ls` command has the parameterized type `List<String>`. When the `List`
1947     referenced by `l` is assigned to `ls`, the compiler generates an unchecked
1948     warning. At compile time, the compiler and JVM cannot determine whether `l`
1949     refers to a `List<String>` type. In this case, `l` does not refer to a
1950     `List<String>` type. As a result, heap pollution occurs.
1951 
1952     A heap pollution situation occurs when the `List` object `l`, whose static
1953     type is `List<Number>`, is assigned to another `List` object, `ls`, that
1954     has a different static type, `List<String>`. However, the compiler still
1955     allows this assignment. It must allow this assignment to preserve backward
1956     compatibility with releases of Java SE that do not support generics. Because
1957     of type erasure, `List<Number>` and `List<String>` both become `List`.
1958     Consequently, the compiler allows the assignment of the object `l`, which
1959     has a raw type of `List`, to the object `ls`.
1960 
1961 `varargs`
1962 :   Warns about unsafe use of variable arguments (`varargs`) methods, in
1963     particular, those that contain non-reifiable arguments, for example:
1964 
1965     ```
1966     public class ArrayBuilder {
1967       public static <T> void addToList (List<T> listArg, T... elements) {
1968         for (T x : elements) {
1969           listArg.add(x);
1970         }
1971       }
1972     }
1973     ```
1974 
1975     A non-reifiable type is a type whose type information is not fully available
1976     at runtime.
1977 
1978     The compiler generates the following warning for the definition of the
1979     method `ArrayBuilder.addToList`:
1980 
1981     ```
1982     warning: [varargs] Possible heap pollution from parameterized vararg type T
1983     ```
1984 
1985     When the compiler encounters a varargs method, it translates the `varargs`
1986     formal parameter into an array. However, the Java programming language
1987     does not permit the creation of arrays of parameterized types. In the method
1988     `ArrayBuilder.addToList`, the compiler translates the `varargs` formal
1989     parameter `T...` elements to the formal parameter `T[]` elements, an array.
1990     However, because of type erasure, the compiler converts the `varargs`
1991     formal parameter to `Object[]` elements. Consequently, there's a
1992     possibility of heap pollution.