1javac(1) Basic Tools javac(1)
2
6 javac - Reads Java class and interface definitions and compiles them
7 into bytecode and class files.
8
10 javac [ options ] [ sourcefiles ] [ classes] [ @argfiles ]
11 Arguments can be in any order:
13 options
15 Command-line options. See Options.
16 sourcefiles
18 One or more source files to be compiled (such as MyClass.java).
19 classes
21 One or more classes to be processed for annotations (such as
22 MyPackage.MyClass).
23 @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
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 There are two ways to pass source code file names to javac.
36 · For a small number of source files, list the file names on the
38 command line.
39 · 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 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 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 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 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
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 · See also Cross-Compilation Options
71 · See also Nonstandard Options
73 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 -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 If the -sourcepath option is not specified, then the user class
90 path is also searched for source files.
91 If the -processorpath option is not specified, then the class
93 path is also searched for annotation processors.
94 -Djava.ext.dirs=directories
96 Overrides the location of installed extensions.
97 -Djava.endorsed.dirs=directories
99 Overrides the location of the endorsed standards path.
100 -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 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 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 Note: The directory specified by the -d option is not
117 automatically added to your user class path.
118 -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 -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 -endorseddirs directories
132 Overrides the location of the endorsed standards path.
133 -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 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 -g
147 Generates all debugging information, including local variables.
148 By default, only line number and source file information is
149 generated.
150 -g:none
152 Does not generate any debugging information.
153 -g:[keyword list]
155 Generates only some kinds of debugging information, specified by
156 a comma separated list of keywords. Valid keywords are:
157 source Source file debugging information.
159 lines Line number debugging information.
161 vars Local variable debugging information.
163 -help
166 Prints a synopsis of standard options.
167 -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 -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 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 -nowarn
194 Disables warning messages. This option operates the same as the
195 -Xlint:none option.
196 -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 -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 -processor class1 [,class2,class3...]
210 Names of the annotation processors to run. This bypasses the
211 default discovery process.
212 -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 -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 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 -source release
229 Specifies the version of source code accepted. The following
230 values for release are allowed:
231 1.3 The compiler does not support assertions, generics, or
233 other language features introduced after Java SE 1.3.
234 1.4 The compiler accepts code containing assertions, which
236 were introduced in Java SE 1.4.
237 1.5 The compiler accepts code containing generics and other
239 language features introduced in Java SE 5.
240 5 Synonym for 1.5.
242 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 6 Synonym for 1.6.
249 1.7 The compiler accepts code with features introduced in
251 Java SE 7.
252 7 Synonym for 1.7.
254 1.8 This is the default value. The compiler accepts code with
256 features introduced in Java SE 8.
257 8 Synonym for 1.8.
259 -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 Note: Classes found through the class path might be recompiled
270 when their source files are also found. See Searching for Types.
271 -verbose
273 Uses verbose output, which includes information about each class
274 loaded and each source file compiled.
275 -version
277 Prints release information.
278 -werror
280 Terminates compilation when warnings occur.
281 -X
283 Displays information about nonstandard options and exits.
284 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 -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 The default for the -target option depends on the value of the
301 -source option:
302 · If the -source option is not specified, then the value of the
304 -target option is 1.8
305 · If the -source option is 1.2, then the value of the -target
307 option is 1.4
308 · If the -source option is 1.3, then the value of the -target
310 option is 1.4
311 · If the -source option is 1.5, then the value of the -target
313 option is 1.8
314 · If the -source option is 1.6, then the value of the -target is
316 option 1.8
317 · If the -source option is 1.7, then the value of the -target is
319 option 1.8
320 · For all other values of the -source option, the value of the
322 -target option is the value of the -source option.
323 -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 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 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 -profile
345 When using compact profiles, this option specifies the profile
346 name when compiling. For example:
347 javac -profile compact1 Hello.java
349 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 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 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 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 NONSTANDARD OPTIONS
377 -Xbootclasspath/p:path
378 Adds a suffix to the bootstrap class path.
379 -Xbootclasspath/a:path
381 Adds a prefix to the bootstrap class path.
382 -Xbootclasspath/:path
384 Overrides the location of the bootstrap class files.
385 -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 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 -Xdoclint:all/protected
402 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 -Xdoclint:all,-html/package
411 -Xdoclint:none
415 Disables all groups of checks.
416 -Xdoclint:all[/access]
418 Enables all groups of checks.
419 -Xlint
421 Enables all recommended warnings. In this release, enabling all
422 available warnings is recommended.
423 -Xlint:all
425 Enables all recommended warnings. In this release, enabling all
426 available warnings is recommended.
427 -Xlint:none
429 Disables all warnings.
430 -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 -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 -Xmaxerrs number
442 Sets the maximum number of errors to print.
443 -Xmaxwarns number
445 Sets the maximum number of warnings to print.
446 -Xstdout filename
448 Sends compiler messages to the named file. By default, compiler
449 messages go to System.err.
450 -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 -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 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 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 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 nonempty
481 Generate a package-info.class file only if package-
482 info.java contains annotations with RetentionPolicy.CLASS
483 or RetentionPolicy.RUNTIME.
484 -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 -XprintProcessorInfo
492 Prints information about which annotations a processor is asked
493 to process.
494 -XprintRounds
496 Prints information about initial and subsequent annotation
497 processing rounds.
498
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 cast Warns about unnecessary and redundant casts, for example:
505 String s = (String) "Hello!"
507 classfile
511 Warns about issues related to class file contents.
512 deprecation
514 Warns about the use of deprecated items, for example:
515 java.util.Date myDate = new java.util.Date();
517 int currentDay = myDate.getDay();
518 The method java.util.Date.getDay has been deprecated since JDK
522 1.1
523 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 /**
530 * @deprecated As of Java SE 7, replaced by {@link #newMethod()}
531 */
532 public static void deprecatedMethood() { }
533 public static void newMethod() { }
534 divzero
538 Warns about division by the constant integer 0, for example:
539 int divideByZero = 42 / 0;
541 empty Warns about empty statements after ifstatements, for example:
545 class E {
547 void m() {
548 if (true) ;
549 }
550 }
551 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 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 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 finally
578 Warns about finally clauses that cannot complete normally, for
579 example:
580 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 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 options
603 Warns about issues that related to the use of command-line
604 options. See Cross-Compilation Options.
605 overrides
607 Warns about issues regarding method overrides. For example,
608 consider the following two classes:
609 public class ClassWithVarargsMethod {
611 void varargsMethod(String... s) { }
612 }
613 public class ClassWithOverridingMethod extends ClassWithVarargsMethod {
614 @Override
615 void varargsMethod(String[] s) { }
616 }
617 The compiler generates a warning similar to the following:.
621 warning: [override] varargsMethod(String[]) in ClassWithOverridingMethod
623 overrides varargsMethod(String...) in ClassWithVarargsMethod; overriding
624 method is missing '...'
625 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 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 javac -Xlint:path -classpath /nonexistentpath Example.java
642 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 Source file AnnocProc.java:
653 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 Source file AnnosWithoutProcessors.java:
671 @interface Anno { }
673 @Anno
674 class AnnosWithoutProcessors { }
675 The following commands compile the annotation processor
679 AnnoProc, then run this annotation processor against the source
680 file AnnosWithoutProcessors.java:
681 javac AnnoProc.java
683 javac -cp . -Xlint:processing -processor AnnoProc -proc:only AnnosWithoutProcessors.java
684 When the compiler runs the annotation processor against the
688 source file AnnosWithoutProcessors.java, it generates the
689 following warning:
690 warning: [processing] No processor claimed any of these annotations: Anno
692 To resolve this issue, you can rename the annotation defined and
696 used in the class AnnosWithoutProcessors from Anno to NotAnno.
697 rawtypes
699 Warns about unchecked operations on raw types. The following
700 statement generates a rawtypes warning:
701 void countElements(List l) { ... }
703 The following example does not generate a rawtypes warning
707 void countElements(List<?> l) { ... }
709 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 Serial Warns about missing serialVersionUID definitions on serializable
720 classes, for example:
721 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 The compiler generates the following warning:
736 warning: [serial] serializable class PersistentTime has no definition of
738 serialVersionUID
739 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 static Warns about issues relating to the use of statics, for example:
758 class XLintStatic {
760 static void m1() { }
761 void m2() { this.m1(); }
762 }
763 The compiler generates the following warning:
767 warning: [static] static method should be qualified by type name,
769 XLintStatic, instead of by an expression
770 To resolve this issue, you can call the static method m1 as
774 follows:
775 XLintStatic.m1();
777 Alternately, you can remove the static keyword from the
781 declaration of the method m1.
782 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 try ( AutoCloseable ac = getResource() ) { // do nothing}
789 unchecked
793 Gives more detail for unchecked conversion warnings that are
794 mandated by the Java Language Specification, for example:
795 List l = new ArrayList<Number>();
797 List<String> ls = l; // unchecked warning
798 During type erasure, the types ArrayList<Number> and
802 List<String> become ArrayList and List, respectively.
803 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 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 varargs
822 Warns about unsafe usages of variable arguments (varargs)
823 methods, in particular, those that contain non-reifiable
824 arguments, for example:
825 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 Note: A non-reifiable type is a type whose type information is
837 not fully available at runtime.
838 The compiler generates the following warning for the definition
840 of the method ArrayBuilder.addToList
841 warning: [varargs] Possible heap pollution from parameterized vararg type T
843 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
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 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 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 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 Example 1 Single Argument File
880 You could use a single argument file named argfile to hold all javac
882 arguments:
883 javac @argfile
885 This argument file could contain the contents of both files shown in
887 Example 2
888 Example 2 Two Argument Files
890 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 Create a file named options that contains the following:
896 -d classes
898 -g
899 -sourcepath /java/pubs/ws/1.3/src/share/classes
900 Create a file named classes that contains the following:
902 MyClass1.java
904 MyClass2.java
905 MyClass3.java
906 Then, run the javac command as follows:
908 javac @options @classes
910 Example 3 Argument Files with Paths
912 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 javac @path1/options @path2/classes
917
920 The javac command provides direct support for annotation processing,
921 superseding the need for the separate annotation processing command,
922 apt.
923 The API for annotation processors is defined in the
925 javax.annotation.processing and javax.lang.model packages and
926 subpackages.
927 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 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 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 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 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
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 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 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 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 You can specify different bootstrap or extension classes with the
991 -bootclasspath and the -extdirs options. See Cross-Compilation Options.
992 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 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 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
1017 The javac command supports the new Java Compiler API defined by the
1018 classes and interfaces in the javax.tools package.
1019 EXAMPLE
1021 To compile as though providing command-line arguments, use the
1022 following syntax:
1023 JavaCompiler javac = ToolProvider.getSystemJavaCompiler();
1025 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 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 OLD INTERFACE
1035 Note: This API is retained for backward compatibility only. All new
1036 code should use the newer Java Compiler API.
1037 The com.sun.tools.javac.Main class provides two static methods to call
1039 the compiler from a program:
1040 public static int compile(String[] args);
1042 public static int compile(String[] args, PrintWriter out);
1043 The args parameter represents any of the command-line arguments that
1045 would typically be passed to the compiler.
1046 The out parameter indicates where the compiler diagnostic output is
1048 directed.
1049 The return value is equivalent to the exit value from javac.
1051 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
1057 Example 1 Compile a Simple Program
1058 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 The source code in Hello.java:
1068 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 Compile greetings.Hello:
1079 javac greetings/Hello.java
1081 Run greetings.Hello:
1083 java greetings.Hello World Universe Everyone
1085 Hello World
1086 Hello Universe
1087 Hello Everyone
1088 Example 2 Compile Multiple Source Files
1090 This example compiles the Aloha.java, GutenTag.java, Hello.java, and
1092 Hi.java source files in the greetings package.
1093 % 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 Example 3 Specify a User Class Path
1100 After changing one of the source files in the previous example,
1102 recompile it:
1103 pwd
1105 /examples
1106 javac greetings/Hi.java
1107 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 javac -classpath /examples /examples/greetings/Hi.java
1117 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 javac -classpath /examples:/lib/Banners.jar \
1122 /examples/greetings/Hi.java
1123 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 java -classpath /examples:/lib/Banners.jar greetings.Hi
1129 Example 4 Separate Source Files and Class Files
1131 The following example uses javac to compile code that runs on JVM 1.7.
1133 javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
1135 -extdirs "" OldCode.java
1136 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 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 javac -source 1.7 OldCode.java
1149 warning: [options] bootstrap class path not set in conjunction with
1150 -source 1.7
1151 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 Example 5 Cross Compile
1160 This example uses javac to compile code that runs on JVM 1.7.
1162 javac -source 1.7 -target 1.7 -bootclasspath jdk1.7.0/lib/rt.jar \
1164 -extdirs "" OldCode.java
1165 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 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 javac -source 1.7 OldCode.java
1176 warning: [options] bootstrap class path not set in conjunction with -source 1.7
1177 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
1186 · java(1)
1187 · jdb(1)
1189 · javah(1)
1191 · javadoc(1)
1193 · jar(1)
1195 · jdb(1)
1197JDK 8 03 March 2015 javac(1)