Ouch thats bad.

Look to the documentation for java.exe switches. It might be solvable purely with -cp switch or wasn''t there bootstrap...
Well if all fails you could at least try to write some code at work and compile it at home, thus save some time.

"classpath1;classpath2
Class paths to the .jar, .zip or .class files. Each classpath should end with a filename or directory depending on what you are setting the class path to:
For a .jar or .zip file that contains .class files, the class path ends with the name of the .zip or .jar file.
For .class files in an unnamed package, the class path ends with the directory that contains the .class files.
For .class files in a named package, the class path ends with the directory that contains the "root" package (the first package in the full package name).

The default class path is the current directory. Setting the CLASSPATH variable or using the -classpath command-line option overrides that default, so if you want to include the current directory in the search path, you must include "." in the new settings.

It is very unlikely that you will need to redefine the bootstrap class path. The nonstandard option, -Xbootclasspath, allows you to do so in those rare cicrcumstances in which it is necessary to use a different set of core classes.

Note that the classes which implement the Java 2 SDK tools are in separate archive from the bootstrap classes. The tools archive is the SDK''s/lib/tools.jar file. The development tools add this archive to the user class path when invoking the launcher. However, this augmented user class path is only used to execute the tool. The tools that process source code, javac and javadoc, use the original class path, not the augmented version."


So you''d need to set path to rt.jar and to tools.jar
-classpath /somedirectory/rt.jar; and so on.


Hope that helps.