1javac(1)                          Basic Tools                         javac(1)
2
3
4

NAME

6       javac - Reads Java class and interface definitions and compiles them
7       into bytecode and class files.
8

SYNOPSIS

10       javac [ options ] [ sourcefiles ] [ classes] [ @argfiles ]
11
12       Arguments can be in any order:
13
14       options
15              Command-line options. See Options.
16
17       sourcefiles
18              One or more source files to be compiled (such as MyClass.java).
19
20       classes
21              One or more classes to be processed for annotations (such as
22              MyPackage.MyClass).
23
24       @argfiles
25              One or more files that list options and source files. The -J
26              options are not allowed in these files. See Command-Line
27              Argument Files.
28

DESCRIPTION

30       The javac command reads class and interface definitions, written in the
31       Java programming language, and compiles them into bytecode class files.
32       The javac command can also process annotations in Java source files and
33       classes.
34
35       There are two ways to pass source code file names to javac.
36
37       · For a small number of source files, list the file names on the
38         command line.
39
40       · For a large number of source files, list the file names in a file
41         that is separated by blanks or line breaks. Use the list file name
42         preceded by an at sign (@) with the javac command.
43
44       Source code file names must have .java suffixes, class file names must
45       have .class suffixes, and both source and class files must have root
46       names that identify the class. For example, a class called MyClass
47       would be written in a source file called MyClass.java and compiled into
48       a bytecode class file called MyClass.class.
49
50       Inner class definitions produce additional class files. These class
51       files have names that combine the inner and outer class names, such as
52       MyClass$MyInnerClass.class.
53
54       Arrange source files in a directory tree that reflects their package
55       tree. For example, if all of your source files are in /workspace, then
56       put the source code for com.mysoft.mypack.MyClass in
57       /workspace/com/mysoft/mypack/MyClass.java.
58
59       By default, the compiler puts each class file in the same directory as
60       its source file. You can specify a separate destination directory with
61       the -d option.
62

OPTIONS

64       The compiler has a set of standard options that are supported on the
65       current development environment. An additional set of nonstandard
66       options are specific to the current virtual machine and compiler
67       implementations and are subject to change in the future. Nonstandard
68       options begin with the -X option.
69
70       · See also Cross-Compilation Options
71
72       · See also Nonstandard Options
73
74   STANDARD OPTIONS
75       -Akey[=value]
76              Specifies options to pass to annotation processors. These
77              options are not interpreted by javac directly, but are made
78              available for use by individual processors. The key value should
79              be one or more identifiers separated by a dot (.).
80
81       -cp path or -classpath path
82              Specifies where to find user class files, and (optionally)
83              annotation processors and source files. This class path
84              overrides the user class path in the CLASSPATH environment
85              variable. If neither CLASSPATH, -cp nor -classpath is specified,
86              then the user class path is the current directory. See Setting
87              the Class Path.
88
89              If the -sourcepath option is not specified, then the user class
90              path is also searched for source files.
91
92              If the -processorpath option is not specified, then the class
93              path is also searched for annotation processors.
94
95       -Djava.ext.dirs=directories
96              Overrides the location of installed extensions.
97
98       -Djava.endorsed.dirs=directories
99              Overrides the location of the endorsed standards path.
100
101       -d directory
102              Sets the destination directory for class files. The directory
103              must already exist because javac does not create it. If a class
104              is part of a package, then javac puts the class file in a
105              subdirectory that reflects the package name and creates
106              directories as needed.
107
108              If you specify -d/home/myclasses and the class is called
109              com.mypackage.MyClass, then the class file is
110              /home/myclasses/com/mypackage/MyClass.class.
111
112              If the -d option is not specified, then javac puts each class
113              file in the same directory as the source file from which it was
114              generated.
115
116              Note: The directory specified by the -d option is not
117              automatically added to your user class path.
118
119       -deprecation
120              Shows a description of each use or override of a deprecated
121              member or class. Without the -deprecation option, javac shows a
122              summary of the source files that use or override deprecated
123              members or classes. The -deprecation option is shorthand for
124              -Xlint:deprecation.
125
126       -encoding encoding
127              Sets the source file encoding name, such as EUC-JP and UTF-8. If
128              the -encoding option is not specified, then the platform default
129              converter is used.
130
131       -endorseddirs directories
132              Overrides the location of the endorsed standards path.
133
134       -extdirs directories
135              Overrides the location of the ext directory. The directories
136              variable is a colon-separated list of directories. Each JAR file
137              in the specified directories is searched for class files. All
138              JAR files found become part of the class path.
139
140              If you are cross-compiling (compiling classes against bootstrap
141              and extension classes of a different Java platform
142              implementation), then this option specifies the directories that
143              contain the extension classes. See Cross-Compilation Options for
144              more information.
145
146       -g
147              Generates all debugging information, including local variables.
148              By default, only line number and source file information is
149              generated.
150
151       -g:none
152              Does not generate any debugging information.
153
154       -g:[keyword list]
155              Generates only some kinds of debugging information, specified by
156              a comma separated list of keywords. Valid keywords are:
157
158              source Source file debugging information.
159
160              lines  Line number debugging information.
161
162              vars   Local variable debugging information.
163
164
165       -help
166              Prints a synopsis of standard options.
167
168       -implicit:[class, none]
169              Controls the generation of class files for implicitly loaded
170              source files. To automatically generate class files, use
171              -implicit:class. To suppress class file generation, use
172              -implicit:none. If this option is not specified, then the
173              default is to automatically generate class files. In this case,
174              the compiler issues a warning if any such class files are
175              generated when also doing annotation processing. The warning is
176              not issued when the -implicit option is set explicitly. See
177              Searching for Types.
178
179       -Joption
180              Passes option to the Java Virtual Machine (JVM), where option is
181              one of the options described on the reference page for the Java
182              launcher. For example, -J-Xms48m sets the startup memory to 48
183              MB. See java(1).
184
185              Note: The CLASSPATH, -classpath, -bootclasspath, and -extdirs
186              options do not specify the classes used to run javac. Trying to
187              customize the compiler implementation with these options and
188              variables is risky and often does not accomplish what you want.
189              If you must customize the complier implementation, then use the
190              -J option to pass options through to the underlying Java
191              launcher.
192
193       -nowarn
194              Disables warning messages. This option operates the same as the
195              -Xlint:none option.
196
197       -parameters
198              Stores formal parameter names of constructors and methods in the
199              generated class file so that the method
200              java.lang.reflect.Executable.getParameters from the Reflection
201              API can retrieve them.
202
203       -proc: [none, only]
204              Controls whether annotation processing and compilation are done.
205              -proc:none means that compilation takes place without annotation
206              processing. -proc:only means that only annotation processing is
207              done, without any subsequent compilation.
208
209       -processor class1 [,class2,class3...]
210              Names of the annotation processors to run. This bypasses the
211              default discovery process.
212
213       -processorpath path
214              Specifies where to find annotation processors. If this option is
215              not used, then the class path is searched for processors.
216
217       -s dir
218              Specifies the directory where to place the generated source
219              files. The directory must already exist because javac does not
220              create it. If a class is part of a package, then the compiler
221              puts the source file in a subdirectory that reflects the package
222              name and creates directories as needed.
223
224              If you specify -s /home/mysrc and the class is called
225              com.mypackage.MyClass, then the source file is put in
226              /home/mysrc/com/mypackage/MyClass.java.
227
228       -source release
229              Specifies the version of source code accepted. The following
230              values for release are allowed:
231
232              1.3    The compiler does not support assertions, generics, or
233                     other language features introduced after Java SE 1.3.
234
235              1.4    The compiler accepts code containing assertions, which
236                     were introduced in Java SE 1.4.
237
238              1.5    The compiler accepts code containing generics and other
239                     language features introduced in Java SE 5.
240
241              5      Synonym for 1.5.
242
243              1.6    No language changes were introduced in Java SE 6.
244                     However, encoding errors in source files are now reported
245                     as errors instead of warnings as in earlier releases of
246                     Java Platform, Standard Edition.
247
248              6      Synonym for 1.6.
249
250              1.7    The compiler accepts code with features introduced in
251                     Java SE 7.
252
253              7      Synonym for 1.7.
254
255              1.8    This is the default value. The compiler accepts code with
256                     features introduced in Java SE 8.
257
258              8      Synonym for 1.8.
259
260
261       -sourcepath sourcepath
262              Specifies the source code path to search for class or interface
263              definitions. As with the user class path, source path entries
264              are separated by colons (:) on Oracle Solaris and semicolons on
265              Windows and can be directories, JAR archives, or ZIP archives.
266              If packages are used, then the local path name within the
267              directory or archive must reflect the package name.
268
269              Note: Classes found through the class path might be recompiled
270              when their source files are also found. See Searching for Types.
271
272       -verbose
273              Uses verbose output, which includes information about each class
274              loaded and each source file compiled.
275
276       -version
277              Prints release information.
278
279       -werror
280              Terminates compilation when warnings occur.
281
282       -X
283              Displays information about nonstandard options and exits.
284
285   CROSS-COMPILATION OPTIONS
286       By default, classes are compiled against the bootstrap and extension
287       classes of the platform that javac shipped with. But javac also
288       supports cross-compiling, where classes are compiled against a
289       bootstrap and extension classes of a different Java platform
290       implementation. It is important to use the -bootclasspath and -extdirs
291       options when cross-compiling.
292
293       -target version
294              Generates class files that target a specified release of the
295              virtual machine. Class files will run on the specified target
296              and on later releases, but not on earlier releases of the JVM.
297              Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also
298              6), 1.7 (also 7), and 1.8 (also 8).
299
300              The default for the -target option depends on the value of the
301              -source option:
302
303              · If the -source option is not specified, then the value of the
304                -target option is 1.8
305
306              · If the -source option is 1.2, then the value of the -target
307                option is 1.4
308
309              · If the -source option is 1.3, then the value of the -target
310                option is 1.4
311
312              · If the -source option is 1.5, then the value of the -target
313                option is 1.8
314
315              · If the -source option is 1.6, then the value of the -target is
316                option 1.8
317
318              · If the -source option is 1.7, then the value of the -target is
319                option 1.8
320
321              · For all other values of the -source option, the value of the
322                -target option is the value of the -source option.
323
324
325       -bootclasspath bootclasspath
326              Cross-compiles against the specified set of boot classes. As
327              with the user class path, boot class path entries are separated
328              by colons (:) and can be directories, JAR archives, or ZIP
329              archives.
330
331   COMPACT PROFILE OPTION
332       Beginning with JDK 8, the javac compiler supports compact profiles.
333       With compact profiles, applications that do not require the entire Java
334       platform can be deployed and run with a smaller footprint. The compact
335       profiles feature could be used to shorten the download time for
336       applications from app stores. This feature makes for more compact
337       deployment of Java applications that bundle the JRE. This feature is
338       also useful in small devices.
339
340       The supported profile values are compact1, compact2, and compact3.
341       These are additive layers. Each higher-numbered compact profile
342       contains all of the APIs in profiles with smaller number names.
343
344       -profile
345              When using compact profiles, this option specifies the profile
346              name when compiling. For example:
347
348              javac -profile compact1 Hello.java
349
350
351
352              javac does not compile source code that uses any Java SE APIs
353              that is not in the specified profile. Here is an example of the
354              error message that results from attempting to compile such
355              source code:
356
357              cd jdk1.8.0/bin
358              ./javac -profile compact1 Paint.java
359              Paint.java:5: error: Applet is not available in profile 'compact1'
360              import java.applet.Applet;
361
362
363
364              In this example, you can correct the error by modifying the
365              source to not use the Applet class. You could also correct the
366              error by compiling without the -profile option. Then the
367              compilation would be run against the full set of Java SE APIs.
368              (None of the compact profiles include the Applet class.)
369
370              An alternative way to compile with compact profiles is to use
371              the -bootclasspath option to specify a path to an rt.jar file
372              that specifies a profile's image. Using the -profile option
373              instead does not require a profile image to be present on the
374              system at compile time. This is useful when cross-compiling.
375
376   NONSTANDARD OPTIONS
377       -Xbootclasspath/p:path
378              Adds a suffix to the bootstrap class path.
379
380       -Xbootclasspath/a:path
381              Adds a prefix to the bootstrap class path.
382
383       -Xbootclasspath/:path
384              Overrides the location of the bootstrap class files.
385
386       -Xdoclint:[-]group [/access]
387              Enables or disables specific groups of checks, where group is
388              one of the following values: accessibility, syntax, reference,
389              html or missing. For more information about these groups of
390              checks see the -Xdoclint option of the javadoc command. The
391              -Xdoclint option is disabled by default in the javac command.
392
393              The variable access specifies the minimum visibility level of
394              classes and members that the -Xdoclint option checks. It can
395              have one of the following values (in order of most to least
396              visible) : public, protected, package and private. For example,
397              the following option checks classes and members (with all groups
398              of checks) that have the access level protected and higher
399              (which includes protected, package and public):
400
401              -Xdoclint:all/protected
402
403
404
405              The following option enables all groups of checks for all access
406              levels, except it will not check for HTML errors for classes and
407              members that have access level package and higher (which
408              includes package and public):
409
410              -Xdoclint:all,-html/package
411
412
413
414       -Xdoclint:none
415              Disables all groups of checks.
416
417       -Xdoclint:all[/access]
418              Enables all groups of checks.
419
420       -Xlint
421              Enables all recommended warnings. In this release, enabling all
422              available warnings is recommended.
423
424       -Xlint:all
425              Enables all recommended warnings. In this release, enabling all
426              available warnings is recommended.
427
428       -Xlint:none
429              Disables all warnings.
430
431       -Xlint:name
432              Disables warning name. See Enable or Disable Warnings with the
433              -Xlint Option for a list of warnings you can disable with this
434              option.
435
436       -Xlint:-name
437              Disables warning name. See Enable or Disable Warnings with the
438              -Xlint Option with the -Xlint option to get a list of warnings
439              that you can disable with this option.
440
441       -Xmaxerrs number
442              Sets the maximum number of errors to print.
443
444       -Xmaxwarns number
445              Sets the maximum number of warnings to print.
446
447       -Xstdout filename
448              Sends compiler messages to the named file. By default, compiler
449              messages go to System.err.
450
451       -Xprefer:[newer,source]
452              Specifies which file to read when both a source file and class
453              file are found for a type. (See Searching for Types). If the
454              -Xprefer:newer option is used, then it reads the newer of the
455              source or class file for a type (default). If the
456              -Xprefer:source option is used, then it reads the source file.
457              Use -Xprefer:source when you want to be sure that any annotation
458              processors can access annotations declared with a retention
459              policy of SOURCE.
460
461       -Xpkginfo:[always,legacy,nonempty]
462              Control whether javac generates package-info.class files from
463              package-info.java files. Possible mode arguments for this option
464              include the following.
465
466              always Always generate a package-info.class file for every
467                     package-info.java file. This option may be useful if you
468                     use a build system such as Ant, which checks that each
469                     .java file has a corresponding .class file.
470
471              legacy Generate a package-info.class file only if package-
472                     info.java contains annotations. Don't generate a package-
473                     info.class file if package-info.java only contains
474                     comments.
475
476                     Note: A package-info.class file might be generated but be
477                     empty if all the annotations in the package-info.java
478                     file have RetentionPolicy.SOURCE.
479
480              nonempty
481                     Generate a package-info.class file only if package-
482                     info.java contains annotations with RetentionPolicy.CLASS
483                     or RetentionPolicy.RUNTIME.
484
485
486       -Xprint
487              Prints a textual representation of specified types for debugging
488              purposes. Perform neither annotation processing nor compilation.
489              The format of the output could change.
490
491       -XprintProcessorInfo
492              Prints information about which annotations a processor is asked
493              to process.
494
495       -XprintRounds
496              Prints information about initial and subsequent annotation
497              processing rounds.
498

ENABLE OR DISABLE WARNINGS WITH THE -XLINT OPTION

500       Enable warning name with the -Xlint:name option, where name is one of
501       the following warning names. Note that you can disable a warning with
502       the -Xlint:-name: option.
503
504       cast   Warns about unnecessary and redundant casts, for example:
505
506              String s = (String) "Hello!"
507
508
509
510       classfile
511              Warns about issues related to class file contents.
512
513       deprecation
514              Warns about the use of deprecated items, for example:
515
516              java.util.Date myDate = new java.util.Date();
517              int currentDay = myDate.getDay();
518
519
520
521              The method java.util.Date.getDay has been deprecated since JDK
522              1.1
523
524       dep-ann
525              Warns about items that are documented with an @deprecated
526              Javadoc comment, but do not have a @Deprecated annotation, for
527              example:
528
529              /**
530                * @deprecated As of Java SE 7, replaced by {@link #newMethod()}
531                */
532              public static void deprecatedMethood() { }
533              public static void newMethod() { }
534
535
536
537       divzero
538              Warns about division by the constant integer 0, for example:
539
540              int divideByZero = 42 / 0;
541
542
543
544       empty  Warns about empty statements after ifstatements, for example:
545
546              class E {
547                  void m() {
548                       if (true) ;
549                  }
550              }
551
552
553
554       fallthrough
555              Checks the switch blocks for fall-through cases and provides a
556              warning message for any that are found. Fall-through cases are
557              cases in a switch block, other than the last case in the block,
558              whose code does not include a break statement, allowing code
559              execution to fall through from that case to the next case. For
560              example, the code following the case 1 label in this switch
561              block does not end with a break statement:
562
563              switch (x) {
564              case 1:
565                System.out.println("1");
566                // No break statement here.
567              case 2:
568                System.out.println("2");
569              }
570
571
572
573              If the -Xlint:fallthrough option was used when compiling this
574              code, then the compiler emits a warning about possible fall-
575              through into case, with the line number of the case in question.
576
577       finally
578              Warns about finally clauses that cannot complete normally, for
579              example:
580
581              public static int m() {
582                try {
583                   throw new NullPointerException();
584                }  catch (NullPointerException(); {
585                   System.err.println("Caught NullPointerException.");
586                   return 1;
587                 } finally {
588                   return 0;
589                 }
590                }
591
592
593
594              The compiler generates a warning for the finally block in this
595              example. When the int method is called, it returns a value of 0.
596              A finally block executes when the try block exits. In this
597              example, when control is transferred to the catch block, the int
598              method exits. However, the finally block must execute, so it is
599              executed, even though control was transferred outside the
600              method.
601
602       options
603              Warns about issues that related to the use of command-line
604              options. See Cross-Compilation Options.
605
606       overrides
607              Warns about issues regarding method overrides. For example,
608              consider the following two classes:
609
610              public class ClassWithVarargsMethod {
611                void varargsMethod(String... s) { }
612              }
613              public class ClassWithOverridingMethod extends ClassWithVarargsMethod {
614                 @Override
615                 void varargsMethod(String[] s) { }
616              }
617
618
619
620              The compiler generates a warning similar to the following:.
621
622              warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod
623              overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding
624              method is missing '...'
625
626
627
628              When the compiler encounters a varargs method, it translates the
629              varargs formal parameter into an array. In the method
630              ClassWithVarargsMethod.varargsMethod, the compiler translates
631              the varargs formal parameter String... s to the formal parameter
632              String[] s, an array, which matches the formal parameter of the
633              method ClassWithOverridingMethod.varargsMethod. Consequently,
634              this example compiles.
635
636       path   Warns about invalid path elements and nonexistent path
637              directories on the command line (with regard to the class path,
638              the source path, and other paths). Such warnings cannot be
639              suppressed with the @SuppressWarnings annotation, for example:
640
641              javac -Xlint:path -classpath /nonexistentpath Example.java
642
643
644
645       processing
646              Warn about issues regarding annotation processing. The compiler
647              generates this warning when you have a class that has an
648              annotation, and you use an annotation processor that cannot
649              handle that type of exception. For example, the following is a
650              simple annotation processor:
651
652              Source file AnnocProc.java:
653
654              import java.util.*;
655              import javax.annotation.processing.*;
656              import javax.lang.model.*;
657              import.javaz.lang.model.element.*;
658              @SupportedAnnotationTypes("NotAnno")
659              public class AnnoProc extends AbstractProcessor {
660                public boolean process(Set<? extends TypeElement> elems, RoundEnvironment renv){
661                   return true;
662                }
663                public SourceVersion getSupportedSourceVersion() {
664                   return SourceVersion.latest();
665                 }
666              }
667
668
669
670              Source file AnnosWithoutProcessors.java:
671
672              @interface Anno { }
673              @Anno
674              class AnnosWithoutProcessors { }
675
676
677
678              The following commands compile the annotation processor
679              AnnoProc, then run this annotation processor against the source
680              file AnnosWithoutProcessors.java:
681
682              javac AnnoProc.java
683              javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java
684
685
686
687              When the compiler runs the annotation processor against the
688              source file AnnosWithoutProcessors.java, it generates the
689              following warning:
690
691              warning: [processing] No processor claimed any of these annotations: Anno
692
693
694
695              To resolve this issue, you can rename the annotation defined and
696              used in the class AnnosWithoutProcessors from Anno to NotAnno.
697
698       rawtypes
699              Warns about unchecked operations on raw types. The following
700              statement generates a rawtypes warning:
701
702              void countElements(List l) { ... }
703
704
705
706              The following example does not generate a rawtypes warning
707
708              void countElements(List<?> l) { ... }
709
710
711
712              List is a raw type. However, List<?> is an unbounded wildcard
713              parameterized type. Because List is a parameterized interface,
714              always specify its type argument. In this example, the List
715              formal argument is specified with an unbounded wildcard (?) as
716              its formal type parameter, which means that the countElements
717              method can accept any instantiation of the List interface.
718
719       Serial Warns about missing serialVersionUID definitions on serializable
720              classes, for example:
721
722              public class PersistentTime implements Serializable
723              {
724                private Date time;
725                 public PersistentTime() {
726                   time = Calendar.getInstance().getTime();
727                 }
728                 public Date getTime() {
729                   return time;
730                 }
731              }
732
733
734
735              The compiler generates the following warning:
736
737              warning: [serial] serializable class PersistentTime has no definition of
738              serialVersionUID
739
740
741
742              If a serializable class does not explicitly declare a field
743              named serialVersionUID, then the serialization runtime
744              environment calculates a default serialVersionUID value for that
745              class based on various aspects of the class, as described in the
746              Java Object Serialization Specification. However, it is strongly
747              recommended that all serializable classes explicitly declare
748              serialVersionUID values because the default process of computing
749              serialVersionUID vales is highly sensitive to class details that
750              can vary depending on compiler implementations, and as a result,
751              might cause an unexpected InvalidClassExceptions during
752              deserialization. To guarantee a consistent serialVersionUID
753              value across different Java compiler implementations, a
754              serializable class must declare an explicit serialVersionUID
755              value.
756
757       static Warns about issues relating to the use of statics, for example:
758
759              class XLintStatic {
760                  static void m1() { }
761                  void m2() { this.m1(); }
762              }
763
764
765
766              The compiler generates the following warning:
767
768              warning: [static] static method should be qualified by type name,
769              XLintStatic, instead of by an expression
770
771
772
773              To resolve this issue, you can call the static method m1 as
774              follows:
775
776              XLintStatic.m1();
777
778
779
780              Alternately, you can remove the static keyword from the
781              declaration of the method m1.
782
783       try    Warns about issues relating to use of try blocks, including try-
784              with-resources statements. For example, a warning is generated
785              for the following statement because the resource ac declared in
786              the try block is not used:
787
788              try ( AutoCloseable ac = getResource() ) {    // do nothing}
789
790
791
792       unchecked
793              Gives more detail for unchecked conversion warnings that are
794              mandated by the Java Language Specification, for example:
795
796              List l = new ArrayList<Number>();
797              List<String> ls = l;       // unchecked warning
798
799
800
801              During type erasure, the types ArrayList<Number> and
802              List<String> become ArrayList and List, respectively.
803
804              The ls command has the parameterized type List<String>. When the
805              List referenced by l is assigned to ls, the compiler generates
806              an unchecked warning. At compile time, the compiler and JVM
807              cannot determine whether l refers to a List<String> type. In
808              this case, l does not refer to a List<String> type. As a result,
809              heap pollution occurs.
810
811              A heap pollution situation occurs when the List object l, whose
812              static type is List<Number>, is assigned to another List object,
813              ls, that has a different static type, List<String>. However, the
814              compiler still allows this assignment. It must allow this
815              assignment to preserve backward compatibility with releases of
816              Java SE that do not support generics. Because of type erasure,
817              List<Number> and List<String> both become List. Consequently,
818              the compiler allows the assignment of the object l, which has a
819              raw type of List, to the object ls.
820
821       varargs
822              Warns about unsafe usages of variable arguments (varargs)
823              methods, in particular, those that contain non-reifiable
824              arguments, for example:
825
826              public class ArrayBuilder {
827                public static <T> void addToList (List<T> listArg, T... elements) {
828                  for (T x : elements) {
829                    listArg.add(x);
830                  }
831                }
832              }
833
834
835
836              Note: A non-reifiable type is a type whose type information is
837              not fully available at runtime.
838
839              The compiler generates the following warning for the definition
840              of the method ArrayBuilder.addToList
841
842              warning: [varargs] Possible heap pollution from parameterized vararg type T
843
844
845
846              When the compiler encounters a varargs method, it translates the
847              varargs formal parameter into an array. However, the Java
848              programming language does not permit the creation of arrays of
849              parameterized types. In the method ArrayBuilder.addToList, the
850              compiler translates the varargs formal parameter T... elements
851              to the formal parameter T[] elements, an array. However, because
852              of type erasure, the compiler converts the varargs formal
853              parameter to Object[] elements. Consequently, there is a
854              possibility of heap pollution.
855

COMMAND-LINE ARGUMENT FILES

857       To shorten or simplify the javac command, you can specify one or more
858       files that contain arguments to the javac command (except -J options).
859       This enables you to create javac commands of any length on any
860       operating system.
861
862       An argument file can include javac options and source file names in any
863       combination. The arguments within a file can be separated by spaces or
864       new line characters. If a file name contains embedded spaces, then put
865       the whole file name in double quotation marks.
866
867       File Names within an argument file are relative to the current
868       directory, not the location of the argument file. Wild cards (*) are
869       not allowed in these lists (such as for specifying *.java). Use of the
870       at sign (@) to recursively interpret files is not supported. The -J
871       options are not supported because they are passed to the launcher,
872       which does not support argument files.
873
874       When executing the javac command, pass in the path and name of each
875       argument file with the at sign (@) leading character. When the javac
876       command encounters an argument beginning with the at sign (@), it
877       expands the contents of that file into the argument list.
878
879       Example 1 Single Argument File
880
881       You could use a single argument file named argfile to hold all javac
882       arguments:
883
884       javac @argfile
885
886       This argument file could contain the contents of both files shown in
887       Example 2
888
889       Example 2 Two Argument Files
890
891       You can create two argument files: one for the javac options and the
892       other for the source file names. Note that the following lists have no
893       line-continuation characters.
894
895       Create a file named options that contains the following:
896
897       -d classes
898       -g
899       -sourcepath /java/pubs/ws/1.3/src/share/classes
900
901       Create a file named classes that contains the following:
902
903       MyClass1.java
904       MyClass2.java
905       MyClass3.java
906
907       Then, run the javac command as follows:
908
909       javac @options @classes
910
911       Example 3 Argument Files with Paths
912
913       The argument files can have paths, but any file names inside the files
914       are relative to the current working directory (not path1 or path2):
915
916       javac @path1/options @path2/classes
917
918

ANNOTATION PROCESSING

920       The javac command provides direct support for annotation processing,
921       superseding the need for the separate annotation processing command,
922       apt.
923
924       The API for annotation processors is defined in the
925       javax.annotation.processing and javax.lang.model packages and
926       subpackages.
927
928   HOW ANNOTATION PROCESSING WORKS
929       Unless annotation processing is disabled with the -proc:none option,
930       the compiler searches for any annotation processors that are available.
931       The search path can be specified with the -processorpath option. If no
932       path is specified, then the user class path is used. Processors are
933       located by means of service provider-configuration files named META-
934       INF/services/javax.annotation.processing.Processor on the search path.
935       Such files should contain the names of any annotation processors to be
936       used, listed one per line. Alternatively, processors can be specified
937       explicitly, using the -processor option.
938
939       After scanning the source files and classes on the command line to
940       determine what annotations are present, the compiler queries the
941       processors to determine what annotations they process. When a match is
942       found, the processor is called. A processor can claim the annotations
943       it processes, in which case no further attempt is made to find any
944       processors for those annotations. After all of the annotations are
945       claimed, the compiler does not search for additional processors.
946
947       If any processors generate new source files, then another round of
948       annotation processing occurs: Any newly generated source files are
949       scanned, and the annotations processed as before. Any processors called
950       on previous rounds are also called on all subsequent rounds. This
951       continues until no new source files are generated.
952
953       After a round occurs where no new source files are generated, the
954       annotation processors are called one last time, to give them a chance
955       to complete any remaining work. Finally, unless the -proc:only option
956       is used, the compiler compiles the original and all generated source
957       files.
958
959   IMPLICITLY LOADED SOURCE FILES
960       To compile a set of source files, the compiler might need to implicitly
961       load additional source files. See Searching for Types. Such files are
962       currently not subject to annotation processing. By default, the
963       compiler gives a warning when annotation processing occurred and any
964       implicitly loaded source files are compiled. The -implicit option
965       provides a way to suppress the warning.
966

SEARCHING FOR TYPES

968       To compile a source file, the compiler often needs information about a
969       type, but the type definition is not in the source files specified on
970       the command line. The compiler needs type information for every class
971       or interface used, extended, or implemented in the source file. This
972       includes classes and interfaces not explicitly mentioned in the source
973       file, but that provide information through inheritance.
974
975       For example, when you create a subclass java.applet.Applet, you are
976       also using the ancestor classes of Applet: java.awt.Panel,
977       java.awt.Container, java.awt.Component, and java.lang.Object.
978
979       When the compiler needs type information, it searches for a source file
980       or class file that defines the type. The compiler searches for class
981       files first in the bootstrap and extension classes, then in the user
982       class path (which by default is the current directory). The user class
983       path is defined by setting the CLASSPATH environment variable or by
984       using the -classpath option.
985
986       If you set the -sourcepath option, then the compiler searches the
987       indicated path for source files. Otherwise, the compiler searches the
988       user class path for both class files and source files.
989
990       You can specify different bootstrap or extension classes with the
991       -bootclasspath and the -extdirs options. See Cross-Compilation Options.
992
993       A successful type search may produce a class file, a source file, or
994       both. If both are found, then you can use the -Xprefer option to
995       instruct the compiler which to use. If newer is specified, then the
996       compiler uses the newer of the two files. If source is specified, the
997       compiler uses the source file. The default is newer.
998
999       If a type search finds a source file for a required type, either by
1000       itself, or as a result of the setting for the -Xprefer option, then the
1001       compiler reads the source file to get the information it needs. By
1002       default the compiler also compiles the source file. You can use the
1003       -implicit option to specify the behavior. If none is specified, then no
1004       class files are generated for the source file. If class is specified,
1005       then class files are generated for the source file.
1006
1007       The compiler might not discover the need for some type information
1008       until after annotation processing completes. When the type information
1009       is found in a source file and no -implicit option is specified, the
1010       compiler gives a warning that the file is being compiled without being
1011       subject to annotation processing. To disable the warning, either
1012       specify the file on the command line (so that it will be subject to
1013       annotation processing) or use the -implicit option to specify whether
1014       or not class files should be generated for such source files.
1015

PROGRAMMATIC INTERFACE

1017       The javac command supports the new Java Compiler API defined by the
1018       classes and interfaces in the javax.tools package.
1019
1020   EXAMPLE
1021       To compile as though providing command-line arguments, use the
1022       following syntax:
1023
1024       JavaCompiler javac = ToolProvider.getSystemJavaCompiler();
1025
1026       The example writes diagnostics to the standard output stream and
1027       returns the exit code that javac would give when called from the
1028       command line.
1029
1030       You can use other methods in the javax.tools.JavaCompiler interface to
1031       handle diagnostics, control where files are read from and written to,
1032       and more.
1033
1034   OLD INTERFACE
1035       Note: This API is retained for backward compatibility only. All new
1036       code should use the newer Java Compiler API.
1037
1038       The com.sun.tools.javac.Main class provides two static methods to call
1039       the compiler from a program:
1040
1041       public static int compile(String[] args);
1042       public static int compile(String[] args, PrintWriter out);
1043
1044       The args parameter represents any of the command-line arguments that
1045       would typically be passed to the compiler.
1046
1047       The out parameter indicates where the compiler diagnostic output is
1048       directed.
1049
1050       The return value is equivalent to the exit value from javac.
1051
1052       Note: All other classes and methods found in a package with names that
1053       start with com.sun.tools.javac (subpackages of com.sun.tools.javac) are
1054       strictly internal and subject to change at any time.
1055

EXAMPLES

1057       Example 1 Compile a Simple Program
1058
1059       This example shows how to compile the Hello.java source file in the
1060       greetings directory. The class defined in Hello.java is called
1061       greetings.Hello. The greetings directory is the package directory both
1062       for the source file and the class file and is underneath the current
1063       directory. This makes it possible to use the default user class path.
1064       It also makes it unnecessary to specify a separate destination
1065       directory with the -d option.
1066
1067       The source code in Hello.java:
1068
1069       package greetings;
1070       public class Hello {
1071           public static void main(String[] args) {
1072               for (int i=0; i < args.length; i++) {
1073                   System.out.println("Hello " + args[i]);
1074               }
1075           }
1076       }
1077
1078       Compile greetings.Hello:
1079
1080       javac greetings/Hello.java
1081
1082       Run greetings.Hello:
1083
1084       java greetings.Hello World Universe Everyone
1085       Hello World
1086       Hello Universe
1087       Hello Everyone
1088
1089       Example 2 Compile Multiple Source Files
1090
1091       This example compiles the Aloha.java, GutenTag.java, Hello.java, and
1092       Hi.java source files in the greetings package.
1093
1094       % javac greetings/*.java
1095       % ls greetings
1096       Aloha.class         GutenTag.class      Hello.class         Hi.class
1097       Aloha.java          GutenTag.java       Hello.java          Hi.java
1098
1099       Example 3 Specify a User Class Path
1100
1101       After changing one of the source files in the previous example,
1102       recompile it:
1103
1104       pwd
1105       /examples
1106       javac greetings/Hi.java
1107
1108       Because greetings.Hi refers to other classes in the greetings package,
1109       the compiler needs to find these other classes. The previous example
1110       works because the default user class path is the directory that
1111       contains the package directory. If you want to recompile this file
1112       without concern for which directory you are in, then add the examples
1113       directory to the user class path by setting CLASSPATH. This example
1114       uses the -classpath option.
1115
1116       javac -classpath /examples /examples/greetings/Hi.java
1117
1118       If you change greetings.Hi to use a banner utility, then that utility
1119       also needs to be accessible through the user class path.
1120
1121       javac -classpath /examples:/lib/Banners.jar \
1122                   /examples/greetings/Hi.java
1123
1124       To execute a class in the greetings package, the program needs access
1125       to the greetings package, and to the classes that the greetings classes
1126       use.
1127
1128       java -classpath /examples:/lib/Banners.jar greetings.Hi
1129
1130       Example 4 Separate Source Files and Class Files
1131
1132       The following example uses javac to compile code that runs on JVM 1.7.
1133
1134       javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
1135       -extdirs "" OldCode.java
1136
1137       The -source 1.7 option specifies that release 1.7 (or 7) of the Java
1138       programming language be used to compile OldCode.java. The option
1139       -target 1.7 option ensures that the generated class files are
1140       compatible with JVM 1.7. Note that in most cases, the value of the
1141       -target option is the value of the -source option; in this example, you
1142       can omit the -target option.
1143
1144       You must specify the -bootclasspath option to specify the correct
1145       version of the bootstrap classes (the rt.jar library). If not, then the
1146       compiler generates a warning:
1147
1148       javac -source 1.7 OldCode.java
1149       warning: [options] bootstrap class path not set in conjunction with
1150       -source 1.7
1151
1152       If you do not specify the correct version of bootstrap classes, then
1153       the compiler uses the old language rules (in this example, it uses
1154       version 1.7 of the Java programming language) combined with the new
1155       bootstrap classes, which can result in class files that do not work on
1156       the older platform (in this case, Java SE 7) because reference to
1157       nonexistent methods can get included.
1158
1159       Example 5 Cross Compile
1160
1161       This example uses javac to compile code that runs on JVM 1.7.
1162
1163       javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
1164                   -extdirs "" OldCode.java
1165
1166       The-source 1.7 option specifies that release 1.7 (or 7) of the Java
1167       programming language to be used to compile OldCode.java. The -target
1168       1.7 option ensures that the generated class files are compatible with
1169       JVM 1.7.
1170
1171       You must specify the -bootclasspath option to specify the correct
1172       version of the bootstrap classes (the rt.jar library). If not, then the
1173       compiler generates a warning:
1174
1175       javac -source 1.7 OldCode.java
1176       warning: [options] bootstrap class path not set in conjunction with -source 1.7
1177
1178       If you do not specify the correct version of bootstrap classes, then
1179       the compiler uses the old language rules combined with the new
1180       bootstrap classes. This combination can result in class files that do
1181       not work on the older platform (in this case, Java SE 7) because
1182       reference to nonexistent methods can get included. In this example, the
1183       compiler uses release 1.7 of the Java programming language.
1184

SEE ALSO

1186       · java(1)
1187
1188       · jdb(1)
1189
1190       · javadoc(1)
1191
1192       · jar(1)
1193
1194       · jdb(1)
1195
1196
1197
1198JDK 8                            03 March 2015                        javac(1)
Impressum