As Ben mentioned, preventing the fork (which should cut the classpath size in half), causes the process to hang, so that is not an option.
An easy workaround, theoretically, would be to create an empty jar with the project's classpath specified in the jar's Class-Path manifest attribute. I attempted to do this with Gradle, but it seems Gradle specifies absolute paths for each classpath entry. Apparently, absolute paths are not valid in the manifest's Class-Path attribute. This appears to be true based on Sun's manifest attribute spec at http://download.oracle.com/javase/1.4.2/docs/guide/jar/jar.html, as well as from my personal experience.
Putting the pathing jar concept aside for a moment, it would be nice if Gradle specified relative paths for classpath entries, instead of absolute paths, wherever possible. This, for one, would decrease the size of the classpath. Back to pathing jars: If this behavior is introduced, a pathing jar can be used to address long classpath issues such as this. Note, that for cases where the external dependency cache is not on the same drive as the build/source initially, the GRADLE_USER_HOME env variable can be set to the build/source drive, making it possible to reference these classpath entries relative to the pathing jar.