|Class and File Naming Rules||Ant|
|CLASSPATH And File Naming Recipes||Java Source Code Encoding|
|The Javac.exe Command Line||java.exe|
|Programmatic Javac Invocation||Learning More|
|What Gets Recompiled?||Links|
You cannot put more than one public class inside a *.java file.
Classes in the same package are accessible to each other, even if they are in different files. To access other classes, you must import them.
The source code must be stored in a directory with the same name as the package declared at the top of the file, including case, with the dots replaced by \ or / or whatever your platform uses for directory element separators.
Package names must be lower case, usually beginning com.yourwebsite to ensure global uniqueness.
It is a good idea to put every class in some package. Only experiments you plan to keep for under an hour should be without a package.
If you compile a class, then delete the *.class file and recompile, you will get the exact same *.class file, byte for byte. The time of compilation is not embedded in the file. Of course the new class file will get a new file date. Untouch can be used to put the dates of source and class file back to when they last actually changed.
CD \MyDir javac.exe -classpath . HelloWorld.java
CD \ javac.exe -classpath . com\mindprod\mypackage\HelloWorld.java
|Javac.exe Command Line Switches|
|-g||generate all debugging information|
|-g:none||remove all debugging information|
|-Xdepend||Use a much slower more conservative approach to deciding which files need to be recompiled.|
|-XDignore.symbol.file||Used when you want to use Oracle internal classes. Without it, you do not get access to all the classes in rt.jar just the ones mentioned in lib/ct.sym.|
|-nowarn||suppress warning messages.|
|-verbose||long version of error messages.|
|-classpath /mydir:/place/myCollection.jar||overriding CLASSPATH environment variable, colon/semicolon separated. Infuriatingly, javac.exe won’t let you use the -cp shortcut.|
|-sourcepath /mydir:/place/myCollection.jar||like CLASSPATH but describes with source *.java files are rather than *.class files, colon/semicolon separated.|
|-nowrite||Don’t actually generate code, just check the syntax.|
|-deprecation||warn of any use of any deprecated methods.|
|-d targetDir||Place the output class files in this directory rather than the usual same directory as source.|
|-encoding UTF-8||what encoding was used to create the source files. Lets you embed fancy characters you would otherwise need to encode with \uxxxx.|
|@listOfFiles.txt||To shorten or simplify the javac command, you may specify one or more files that themselves contain one filename per line. This enables you to overcome the command-line length limitation of Windows.|
|-source 1.3||What source code features you plan to use:
|-target 1.1||Specifies which the lowest number of JRE (Java Runtime Environment) you intend to run this code on. You can also specify -target 1.2 and 1.3.|
|-bootclasspath J:\j2sdk1.4.2_19\jre\lib\rt.jar||The compiler is not smart enough to warn you if you use
classes or methods not part of the targeted class library. You have to
discover those errors by runtime tests. In Eclipse and other advanced
IDEs (Integrated Development Environments)
you can configure the Java version 1.5 compiler
to use the Java version 1.4 library if you
have that JRE also installed, which will catch these errors.
If you use -target 1.4 and the 1.5 compiler you can
force the compiler to use the 1.4 classfiles on the command line with
-bootclasspath J:\j2sdk1.4.2_19\jre\lib\rt.jar or -bootclasspath "J:\Program Files\Java\jdk1.6.0_45\jre\lib\rt.jar"That way you can detect use of 1.5 classes that did not exist in 1.4, at compile time, e.g. StringBuilder. You might want to include more of the jars e.g. -bootclasspath J:\Program Files\Java\jdk1.6.0_45\lib;J:\Program Files\Java\jdk1.6.0_45\jre\lib;J:\Program Files\Java\jdk1.6.0_45\jre\lib\ext However, I have not been able to get -bootclasspath listing directories, rather than individual jars to work. A brute force way to handle it is to install the Java version 1.6 JDK and compile with that. In JDK 1.3-, the colours had lower case names such as Color. white. Since these are static final constants, in Java version 1.4 or later, Sun gave them proper upper case names such as Color.WHITE. However, beware of using the upper case names it you want to target JDK 1.3- versions. Your programs will explode in a glory of exceptions from the missing support. The lower case names will work in any JDK version.
|-version||Verify you are using the version of javac.exe you think you are using.|
|-Xstdout||Send error messages to stdout instead of stderr. This makes them easier to redirect to a file in Windows. For some idiotic reason this is no longer supported under Java version 1.3, (a result of intercorporate sniping at Microsoft?) It is supported with oldjavac.exe. Use tcc/TakeCommand to independently redirect stdout and stderr.|
|-Xdoclint||Check for Javadoc problems|
|-Xdiags:verbose||Get a longer version of the error messages|
|-help||Get a list of options and what they do. Trust what it says over what I say here. Knowledge keeps no better than fish.|
|-X||Get a list of the non-standard options. I have listed only the most common ones here.|
In ant, by default, the sourcepath is null in order to suppress recompiling classes outside the package being compiled. This avoids problems with recompiling with the wrong source or target JDK version. Further, ant only recompiles out of date files mentioned on the command line.
When you are testing, sometimes recompiling everything twice is needed to propagate the new versions to all corners, especially when you have jars or circular dependencies between packages i.e. A uses classes of B and B uses classes of A.
Here are cases where javac.exe fails to recompile.
My rule of thumb is to erase all class files before a full application test or release. Also erase them if you suspect you are getting an old class file somewhere along the line. Most of the time, selective recompilation works fine. Usually you make changes to only one java file at a time before recompiling, and none of the other files need it. Any time you change public static final constants is a good time to delete all the class files.
Periodically delete all class files. This cleans up class files from renamed, and deleted source files. It gets rid of unused anonymous inner class files. Strange things can happen when you rename a module, and fail to fix all the references, and still leave the old class file lying about even if you delete the source.
This page is posted
Optional Replicator mirror
Your face IP:[188.8.131.52]
You are visitor number|