How to set a long Java classpath in MSDOS/Windows?

Question

I'm trying to run a particular JUnit test by hand on a Windows XP command line, which has an unusually high number of elements in the class path. I've tried several variations, such as:

set CLASS_PATH=C:\path\a\b\c;C:\path\e\f\g;....
set CLASS_PATH=%CLASS_PATH%;C:\path2\a\b\c;C:\path2\e\f\g;....
...
C:\apps\jdk1.6.0_07\bin\java.exe -client oracle.jdevimpl.junit.runner.TestRunner com.myco.myClass.MyTest testMethod

(Other variations are setting the classpath all on one line, setting the classpath via -classpath as an argument to java"). It always comes down to DOS throwing up it's hands with this error:

The input line is too long.
The syntax of the command is incorrect.

This is a JUnit test testing a rather large existing legacy project, so no suggestions about rearranging my directory structure to something more reasonable, those types of solutions are out for now. I was just trying to gen up a quick test against this project and run it on the command line, and DOS is stonewalling me. Help!

Answer 1

Have you tried stacking them?

set CLASS_PATH = c:\path
set ALT_A = %CLASS_PATH%\a\b\c;
set ALT_B = %CLASS_PATH%\e\f\g;
...

set ALL_PATHS = %CLASS_PATH%;%ALT_A%;%ALT_B%

Answer 2

I think you are up the creek without a paddle here. The commandline has a limit for arguments to call a programm.

I have 2 sugestion you could try. First, prior to running the junit tests, you can let a script/ant_task create JARs of the various classes on the classpath. Then you can put the JARs on the classpath, which should be shorter.

Another way you could try is to create an antscript to run JUNIT, in ANT there should not be such a limit for classpath entries.

Answer 3

(I suppose you do not really mean DOS, but refer to cmd.exe.)

I think it is less a CLASSPATH limitation than a environment size/environment variable size limit. On XP, individual environment variables can be 8k in size, the entire environment is limited to 64k. I can't see you would hit that limit.

There is a limit on windows that restricts the length of a command line, on WindowsNT+ it is 8k for cmd.exe. A set command is subject to that restriction. Can it be you have more than 8k worth of directories in your set command? You may be out of luck, then - even if you split them up like Nick Berardi suggested.

Answer 4

The DOS command line is very limiting in this regard. A workaround is to create a "pathing jar". This is a jar containing only a Mainfest.mf file, whose Class-Path specifies the disk paths of your long list of jars, etc. Now just add this pathing jar to your command line classpath. This is usually more convenient that packaging the actual resources together.

As I recall, the disk paths can be relative to the pathing jar itself. So the Manifest.mf might look something like this:

Class-Path: this.jar that.jar ../lib/other.jar

If your pathing jar contains mainly foundational resources, then it won't change too awfully frequently, but you will probably still want to generate it somewhere in your build. For example:

<jar destfile="pathing.jar">
  <manifest>
    <attribute name="Class-Path" value="this.jar that.jar ../lib/other.jar"/>
  </manifest>
</jar>

Answer 5

You could use classpath wildcards.

Answer 6

As HuibertGill mentions, I would wrap this in an Ant build script just so that you don't have to manage all of this yourself.

Answer 7

if I were in your shoes, I would download the junction utility from MS : http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx and then map your "C:\path" to say, "z:\" and "c:\path2" to say, "y:\". This way, you will be reducing 4 characters per item in your classpath.

set CLASS_PATH=C:\path\a\b\c;C:\path\e\f\g;....
set CLASS_PATH=%CLASS_PATH%;C:\path2\a\b\c;C:\path2\e\f\g;..

Now, your classpath will be :
set CLASS_PATH=z\a\b\c;z\e\f\g;....
set CLASS_PATH=%CLASS_PATH%;y:\a\b\c;y:\e\f\g;..

It might do more depending on your actual classpath.