Work around 32-bit Solaris stdio limit of 256 open files

FULL PRODUCT VERSION :
JRE 1.6.0-b105 (FCS)

ADDITIONAL OS VERSION INFORMATION :
Solaris 10 - 64-bit, SuSE 9, Debian

A DESCRIPTION OF THE PROBLEM :
We have a Java application with a large number of jar files which are included in the classpath. With JRE-1.6.0-b105, when an application is running which loads classes from any of these jar files, /proc/<pid>/fd shows that there is an open file descriptof for every jar file in the classpath. This is not the case with JRE-1.5.0_xx. We are having issues on Solaris 10 with "too many open files" when Java launches a subprocess running the SunStudio 11 cc compiler.

We are trying to upgrade to JRE 6 as a subsystem of MATLAB, but we can't get through our acceptance tests on Solaris with this problem.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run "java -classpath <path to 184 jar files with ":" separators> <class>"
where <class> can be found in one of the jar files in the classpath. Note that there is an open file descriptor for each jar file in /proc/<java-pid>/fd on either Solaris or Linux systems when running with jre-1.6.0-b105.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Behavior similar to jre-1.5.0_07, where only key files (e.g. rt.jar) are held open by the jre.
ACTUAL -
The Java program actually runs correctly, but the large number of open file descriptors seems to have a side effect when launching a "cc" sub-process from java.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
On Solaris, when the Java program launches a "cc" subprocess, it gets several "Too many open files" messages when processing the #include statements. On Solaris "cc" is a 32-bit application, even on a 64-bit system.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
We haven't found one yet. There is a possibility that this new behavior in JRE-1.6.0 is intentional as a performance enhancement, in which case it would be desirable to have an option (e.g. a -XX: option) to disable this behavior.