Compile a lot of .java files listed in a text file, one file name per line. e.g. "manyfiles" contains:

Foo.java
Foohoo.java
Foo2.java

javac @manyfiles

If the source code has a "package" statement (e.g. Foo.java contains "package com.abc.project1;")
Place Foo.java in directory /junk/com/abc/project1javac com/abc/project1/Foo.java

Use "\" in Windowsjavac com\abc\project1\Foo.java

Specify where to start looking for .class files (and .java files if .class not found) if needed during compiling (-classpath) (default is the current working directory)javac -classpath /junk/someDir com/abc/project1/Foo.java

Find where rt.jar file is on your system. Take off /lib/rt.jar from the path. The rest is the path to <java-home>. e.g. /usr/java1.2.2/jre or /usr/java1.1

<java-home>/lib/rt.jar (Automatic)

<java-home>/lib/i18n.jar (Automatic)

<java-home>/lib/ext/*.jar (Automatic) (.class files are ignored)

<java-home>/lib/ext/*.zip (Automatic) (.class files are ignored)

.jar file(s) in the listed order after the -jar command line option, if specified. The -classpath, "CLASSPATH" environment variable and "." current directory are ignored.

Directories, .jar files, .zip file(s) in the listed order after the -classpath command line option, if specified. The "CLASSPATH" environment variable and "." current directory are ignored. Include "." as the current directory to search in -classpath, if desirable. Separate multiple names with a ":". Use ";" on Windows.

Directories, .jar files, .zip file(s) in the listed order as the value of the "CLASSPATH" environment variable, if set. "." current directory is ignored. Include "." as the current working directory to search in the "CLASSPATH" environment variable, if desirable. Separate multiple names with a ":". Use ";" on Windows.

The current working directory (default)

Don't include the package name subdirectories in the above search paths. The compiler starts with the directory, .jar or .zip file that you specify. It automatically appends the package directory structure specified in the "import" statement or inline statement (e.g. "java.util.Properties prop = System.getProperties();") , if needed.

To see what these paths are set to on your computer, run a java program which has the following lines in it:

If javac does not find the .class file it needs, it looks for the corresponding .java file in the -sourcepath directories, .jar or .zip files. (The directories, .jar or .zip files specifed in -classpath or CLASSPATH environment variable are not searched for .java files at all!)

If javac finds both Foo.class (in -classpath directories, .jar or .zip files) and Foo.java (in -sourcepath directories, .jar or .zip files) files, it recompiles Foo.java if Foo.java has newer date and time than Foo.class.

java - Run Java programs

The .java file which must have the following method:public static void main(String args[]){ . . . }

Since "main" method is always static, it cannot use non-static variables which is a severe limitation. (Each variable declared outside the "main" method has to be declared "static".) As a work-around, instantiate a new object of the same class which contains the "main" method. All non-static variables will then become available to "main" method because a particular instance of the class now exists in memory.
e.g., for Foo.java, use:

(The "init" method also doubles as the default applet starting method in case the application needs to be converted to an applet.)

Run a program if its .class file is in the current working directory (Don't specify .class extension)java Foo
Actual program execution starts with the first line in the "main" method.

Run a program from anywhere by specifying -classpathor -cp. (Don't forget to include the current directory as "." if that's what you want!)java -classpath .:/junk/SomeDir Foojava -cp .:/junk/SomeDir Foo

Pass run time "strings" to the "main" method of the compiled programjava -classpath /junk/SomeDir Foo myOption1 myOption2
(Here, "main" method's args[0] will contain the string "myOption1", args[1] will contain the string "myOption2".)

Run a program in a package (com.abc.project1)java -classpath /junk/SomeDir com.abc.project1.Foo

Temporarily change Java's system environment (e.g., set the current working directory by setting "user.dir" to "/junk/someOtherDir")java -classpath /junk/SomeDir -Duser.dir=/junk/someOtherDir com.abc.project1.Foo

Users can also run a Java program directly as a .jar file without knowing the "main" method class name. If Foo.class in myProgram.jar has the "main" method, then you must have modified the MANIFEST.MF file of the myProgram.jar file to include the following line (followed by a blank line):

Main-Class: Foo

Then, anybody can run the program with the following command
java -jar myProgram.jarjava -jar myProgram.jar myOption1 myOption2
Note that Java will ignore any classpath setting when searching for any program classes. All required files must be contained in the .jar file.

In Windows, just double-click the .jar file.
The application will run in the background.
No MSDOS console will appear to show output or get input.
Only if it is a Java Swing application, the swing window will appear as normal.

In unix, set the execute permission on myProgram.jar with chmod 755 program.jar. Then, anybody should be able to run the program by simply issuing the command: myProgram.jarmyProgram.jar myOption1 myOption2

jar - Compress, Bundle-Up, and Extract Files

Create a new .jar file which includes all files in the current working directory (Specify the .jar extension, it is not added automatically)jar cvf myProgram.jar .jar cvf myProgram.jar *

The "META-INF/MANIFEST.MF" manifest text file is automatically created and included in the .jar file. By default, the manifest file contains only one line specifying the version number of the .jar file.

Create a new .jar file which includes specific files in the current working directoryjar cvf myProgram.jar *.class Foo.java ./photo.gif

Temporarily change the current working dircetory before processing files ("*" does not work. Use "." to include all files and directories.)jar cvf myProgram.jar -C /junk/SomeDir .-C seems buggy in Windows.

Create the new .jar file in the specified dirctoryjar cvf /junk/lib/myProgram.jar .

appletviewer - to view applets without a browser

The .java file must contain an "init" method. The first line of the "init" method is the entry point for applet execution. The browser or the appletviewer instantiates a nameless object of the Foo.class using the default constructor which can be empty. Then, the browser will call the "init" method. e.g. In applet Foo.java:

Here, "codebase" <PARAM> is optional. It specifies the directory where the browser will go to retrieve the applet class file as well as any additional class files that may be referenced by the applet class file. The directory should be in the form of a relative URL. When starting with a "/", it is relative to the main world wide web directory of the virtual server. Otherwise, it is relative to the location of the HTML file which contains the applet calling code.

Parameter names are not case-sensitive (trout = Trout = tRout = TROUT). Except for code, codebase, type and version, all other parameter names are made available to the applet class file. e.g.String firstOption = getParameter("Trout"); statement in the applet's .java file will store the string "myOption1" in variable firstOption. Make sure that you check for null before using firstOption further along. The .html author may have forgotten to specify the parameter.

So, for stand alone programs, the end user passes the runtime options on the command line after the class file name. The programmer accesses those runtime options via the "args" String array. For applets, the end user (which is the .html writer) passes the runtime options by specifying values of named parameters in the .html file. The programmer accesses those values by the always-available "getParameter" method. The programmer and the .html writer will have agreed in advance on the name of the parameter which is case-insensitive.

View the applet from the local disk file with no server running (myApplet.html must contain <APPLET>, <OBJECT>, <EMBED> tag.)appletviewer myApplet.htmlappletviewer file:///D:/junk/SomeHtmlDir/myApplet.html
You can specify multiple .html files separated by spaces.

View the applet from the local disk file with a server running locallyappletviewer http://localhost/myApplet.html

<APPLET> works in HTML 3.2 which has no plug-in support and therefore cannot use JApplet available only as a 1.1 or 1.2 plugin. <OBJECT> works in Microsoft Internet Explorer and uses java 1.1 or 1.2 plug-in. <EMBED> works in Netscape Navigator 4.x and also uses java 1.1 or 1.2 plug-in.

You can also view the same applet in a browser. Enter, for example, "d:/junk/SomeHtmlDir/myApplet.html" in the browser's address/location bar and hit enter. The browser will not create a separate applet window as the appletviewer does. Also, "System.out.println( . . .)" statements will not print in the browser window as they do in the MSDOS console window when using appletviewer. So, you may have a difficult time debugging the applet.

On MS Windows 95 and later, to be able to see the output from "System.out.println( . . .)" statements in your programs, you should install JDK 1.2.2 and above. JDK 1.2.2 installs a "Java Plug-In Control Panel" program in "Start->Programs" menu or Windows Control Panel folder. You then enable the "Show Java Console" checkbox in the "Java Plug-In Control Panel" application. Then, everytime you access any applet's HTML file through the browser, a separate window pops up which shows the output from the "System.out.println( . . .)" statements. It also shows all other error and exception information if necessary. (Enabling "java console" in Netscape and MSIE does not work as they can only display the output from the included 1.1.x Java program, not from the plugged-in Java program through the use of <EMBED> and <OBJECT> tags.)

javadoc - Automatic Java Documentation Generator

Include comments starting with /** and ending with */ before each class, variable or method in the original source code. The comments can and should include standard HTML such as <TD>, <B> etc.

An "alias" functions as the name (or handle) for the key-pair for easier use. These aliases are NOT case-sensitive.

Default file for storing keys is the ".keystore" file in "<user.home>" directory. ("System.out.println(System.getProperty("user.home");")

Default file for storing trusted Certificate Authority certificates is the "cacerts" file in "<java.home>/lib/security" directory. Default password is "changeit". The default "cacerts" file that comes with Java already has five VeriSign certificates in it.

Default values for some of the command line options are: -alias "mykey" -keyalg "DSA" -keysize 1024 -validity 90 -keystore <the file named .keystore in the user's home directory> -file <stdin if reading, stdout if writing>

jarsigner - Sign .jar Files Or Verify Their Signatures

Replace a .jar file with its signed versionjarsigner -verbose bundle.jar jane

Digitally "signs" a .jar file with the signer's private key. Stores the corresponding "certificate" containing the signer's public key in the .DSA file which is added to the .jar file's "META-INF" directory.

Can verify and re-sign .jar files signed with the JDK 1.1 "javakey" tool.

Signing a .jar file does not encrypt its contents or change them in any way. Just two new .SF and .DSA files are added to "META-INF" directory inside the .jar file. By default, their file names are taken from up to first 8 characters of the alias name used to sign the .jar file.

After signing, the default manifest file (MANIFEST.MF) contains the signature for each file included in the .jar file. The .SF file contains a signature for each "section" in the MANIFEST.MF file. The .DSA file contains the signature for the whole .SF file and the certificate authenticating the public key of the signer.

What happens during -verify:

Verify the .SF file using the certificate in the .DSA file.

Verify the MANIFEST.MF file using the header in the .SF file.

If the header verification fails, MANIFEST.MF file may have been modified by ADDING files to the .jar file which is fine. The "jarsigner" program will then only check the signed files to see if they have been modified since signing. This is done by verifying each section of the MANIFEST.MF file using the corresponding signature in the .SF file. All signatures in the .SF file must have the corresponding file section in the MANIFEST.MF file.

Then, completely read each file whose signature appears in the .SF file. Verify each file's signature with the signature stored in the MANIFEST.MF file.