Secure Java Development Concepts - Expert Oracle and Java Security - page 30

javac *.java
javac mypkg/*.java
Finding Referenced Code/Classes
There is a “gotcha” with compiling Java that you need to understand and anticipate, or at least quickly
recognize. When your code refers to other Java code that is not on your CLASSPATH , the Java compiler will
not find the code, even if the referenced code is in the current directory. Let's imagine your code is in
package (directory) named mypkg and that your MyApp.java refers to MyRef.java in the same package. If
your CLASSPATH does not refer to the parent directory of the mypkg subdirectory, then javac.exe will not
find the MyRef.java file. Having dot (.) in your CLASSPATH will not fix this gotcha, because the mypkg
directory is not in the current directory, rather we are in mypkg . Remember, CLASSPATH (even dot) is
merely a list of starting places for packages. Looking in the current directory, we cannot find the package
(subdirectory) named mypkg nor the code or class file named mypkg/MyRef.class .
One way to correct that gotcha is to change directories to the parent of mypkg . Once there, you can
compile your code, and the dot (.) in your CLASSPATH will find the referenced code in the mypkg directory.
In this case, however, you need to tell javac.exe that your MyApp.java code is in a subdirectory (both the
forward and back slashes are acceptable as directory separator characters in this context), like this:
javac mypkg/MyApp.java
That is a valid approach, but probably the best way to address this issue is to have a development
directory (like javadev ) and to place all your package directories underneath that directory. Then add
your development directory to your CLASSPATH .
set CLASSPATH = C:\javadev;%CLASSPATH%
Often, especially if you manage your development using an IDE, you will not be able to put your
packages in a single development directory. Each project will store files in a separate directory.
Perhaps now you are thinking, “Man, I'm just going to let the IDE handle all this for me!” I don't
want to disparage IDEs, but being satisfied to take that approach is like voluntarily going to jail because
work is hard. Don't quit working hard! Often you don't need an IDE to write, compile, and run your
code, so take those opportunities to work at the command prompt. Once you set your environment
variables, it is just a matter of knowing about packages and CLASSPATH and recognizing problems.
Running Compiled Code
Once your code is compiled, running (executing) it can be easy:
java mypkg.MyApp
Please observe that to run a Java class, you need to specify the package it is in. There is no shortcut
around this.
The same requirements for finding all classes needed for your application along the CLASSPATH apply
for execution as they do for compiling. In order to run your Java code as just shown, java.exe needs to
be able to find the mypkg package in one of the starting points listed in CLASSPATH . In our example, if you
are in the javadev directory and you have the “dot” in your CLASSPATH , then java . exe can find mypkg , and
can run your code in mypkg/MyApp.class . This must be true for all classes that your code refers to, like
oracle.sql.ARRAY . For that reference, java.exe needs to find ojdbc6.jar listed in CLASSPATH .
There is an alternative to having CLASSPATH defined in your Operating System environment. You can
pass CLASSPATH to java.exe , or javac.exe for that matter, using the - cp parameter.