RE: Jikes file limit?

[Michael McCune <mc...@pop.peoplescape.com>]

It was suggested that I try and increase my NT environment size to try and
get around this problem.  I searched far and wide in order to see if this
was possible, but couldn't find any solution.

So, in response to this problem, I modified the Javac task to split up the
list of files sent to jikes in the doJikesCompile() method.  So if the
number of files to be compiled is over 300 (the magic number here for our NT
systems seemed to be 384 and above) it splits up the list, and calls
compiler.compile() on the separate lists.

This only runs on System.getProperty("os").startsWith("Windows").  I
attached the modified Javac.java file.

Is everyone opposed to this modification?  It took me quite a while to
figure out that jikes wasn't doing anything if the list of files was over
300+ members long, and I don't want anyone else to have to go through this.
We have been using this modification for over a week with no problems, and
we are able to compile our 500+ files without a hitch using Jikes.

Mike

-----Original Message-----
From: Michael McCune [mailto:mccune@pop.peoplescape.com]
Sent: Tuesday, April 25, 2000 1:54 PM
To: ant-dev@jakarta.apache.org
Subject: Jikes file limit?


Suddenly out of the blue, nothing was getting compiled in our project using
ant and jikes.  When we would do a clean build of all our class files, the
build directory would be created, but when the javac task was invoked
(build.compiler="jikes") nothing would happen.  We removed the
build.compiler property so the standard javac would be used and everything
worked just fine.

After confusion and floundering we took a guess that perhaps there was a
physical limit to the number of files that could be compiled by jikes.  We
started deleting files and found that we could compile at a maximum 383
files and nothing more.  If we added one more file up to 384 files, jikes
would appearantly error and not compile a single file in our tree.

I'm assuming this is a limitation of the fact that jikes gets invoked by
exec'ing a process through the command shell and perhaps NT doesn't like
300+ arguments to a command?  Our machines have 384megs of memory, which I'm
assuming is a funny coincidence between the number of files that can/can't
be compiled.

Has anyone seen this?  We've replicated it on a few machines here in our
development environment...  Any thoughts on a work around?  The ugly option
is to re-write the Jikes task to split up the file list and arguments into
multiple commands so this limit doesn't get hit.  My less ugly option is to
switch to JDK 1.3's new "fast" compiler but is not really what I want to do.

Thanks
Mike McCune