Compiling and Launching

javac

• javac by default places the generated class files in the same directory as the source files.
• use the javac -d option to place the class files in some other directory.
• if the directory does not exist, there will be an error.
• the directories for the package structure will however be automatically created by javac.

There are four things to keep in mind while compiling:

• Which are the files that need to be compiled ?
• The directory where javac looks for other .java source files that are used by the file to be compiled.
• The directory where javac looks for class files that are used by the file to be compiled.
• The directory to place the generated class files in.

Options:

• the -sourcepath is the directory where the compiler looks for other java files.
• It has to be the directory that contains the hierarchy of the package structure of the source files.

for e.g. if we are compiling ClassB.java in directory src/net/suhrid/pkgB/ClassB.java which uses ClassA located in net/suhrid/pkgA/pkgA/ClassA.java then argument to sourcepath must be the "src" directory: javac -sourcepath src net/suhrid/pkgB/ClassB.java

• this option will also compile the files which are referenced by the file being compiled.

• -classpath and -cp can be either of the arguments to instruct the compiler to look for classes used by the compiled file.
• Typically used for pre-compiled third party classes/libraries.
• In case of directories, the directory which contains the hierarchy of the package structure of the class files. (similar to sourcepath). This is important:

Assume this directory structure:

somedir

 |
 foo
  |
  bar
   | -- A.class
   | -- B.java

package bar; public class A;

package bar; public class B;

• When in bar directory, javac B.java will not work ! even with the classpath pointing to the current directory.
• Why ? the classpath has to be the location containing the hierarchy of the package structure starting from bar (i.e. foo)

To compile B we can:

1. change to foo directory and then use: javac bar/B.java (since default classpath points to . no need to use -classpath)
2. from testdir : javac -classpath foo foo/bar/B.java

• In case of jar files, the argument is the location of the jar file - including the jar file name. Here the jar file acts as the directory which contains the hierarchy of the package structure of the third party class files.

• Note multiple directories can be specified in the -sourcepath and the -classpath options (separated by ":" in unix and ";" in Windows). Typically the sourcepath will be a single directory whereas the classpath will have multiples directories or jar files for various third party libraries.

java

• Launches the JVM.
• Exactly 1 class must be specified which has the main() method.
• This class name has to be the fully qualified class name.
• java [options] class-name [cmd-line arguments to the class]

cmd-line arguments

• args are space separated.
• If no args are passed, String[] args will be a zero-length array - it won't be null.
• The first-argument is args[0] and the fourth will be args[3]

options

• -D is used to pass properties to the JVM which can be retrieved using System.getProperties().
• e.g. java -Dname=suhrid someclass
• There is no space between -D and the name=value pair!
• -cp / -classpath : same as in javac.

• Order of loading classes

1. Bootstrap classes : Core classes
2. Extensions in jre/lib/ext
3. Defined classpath either through OS env variable or command line. Cmdline ovverrides OS classpath.

• If no classpath is specified, the current directory (from which java is executed) is searched. If a classpath is specified, the current directory (if required) needs to be added explicitly to the classpath.
• As soon as a class is found, jvm will stop searching for that class. So order of specifying is important.

• Note: javac will compile a file even it is not located in the directory structure corresponding to its package.
• java however expects the file to be located in the directory appropriate package.

jar

• jar -cf <jartobecreated.jar> <dirname1-withclasses> <dirname2-withclasses>
• jar is recursive when adding directories

imports

• import is only an alias for a qualified class name. It's only purpose is to save typing and make code more readable.
• import java.util.* will allow us to use HashMap without saying java.util.HashMap everytime
• import java.util.* says use short name for all classes in java.util package ONLY.
• This does not extend to subpackages! for e.g it won't apply to java.util.regex. Import only applies to a single package.
• ambiguous imports and static imports (like using the same classname twice from different packages) will cause compiler errors.

Static imports

• Used to alias a class's static members (field's and methods)
• Has to be "import static" only
• wildcards can be used
• e.g.

import java.util.*;

import static java.lang.System.out;
import static java.lang.Thread.MAX_PRIORITY;
import static java.util.Collections.*;

public class SITest {
	
	public static void main(String[] args) {
		out.println("A thread's max priority is " + MAX_PRIORITY); //instead of System.out.println(Thread.MAX_PRIORITY);
		List<String> aList = new ArrayList<String>(); 
		sort(aList); //Instead of Collections.sort
		binarySearch(aList,"key"); //Instead of Collections.binarySearch
	}
	
}