Problem with AopC Ant Task -- cmd too long!

[squeak]

After following the instructions, and trying to run the AopC ant task, I constantly get the following error:

BUILD FAILED: C:\eclipse\workspace\myproject\build.xml:309: java.io.IOException: CreateProcess: <lots removed>

After much debugging, I have come to the conclusion that the issue stems from a physical limit to the length that a forked-java command can be.

See, when I run the command at the command line with my src dir of my classes being './bin' -- it works fine. However, looking at the code for the AopC and task, it walks through every single directory and appends every single class to compile at the end of the command.

Well, it my case, that generates a String that is ~40k chars long (~200 classes with fullpaths is long!) -- and that is *after* the java command. That is just the length of all of the files it wants to AopCompile. In fact, the command is so long, that I cannot run it at a command promt (WinXP), as it truncates there as well.

Now, when stepping through the debugger for the ant task, and telling it to not fork the command, it works fine as well.

So, is there a reason why the Ant task must list every single file, when the Aop standalone compiler is happy to except a directory?

[squeak]

Wanted to give an update on this for what I found.

It is definetly an issue related to the length of the command that is passed to Runtime.exec.

To experiment, I changed the path that my class are build from long path

c:\eclipse\workspace\myproj\bin

to something very short:

c:\a

Worked great! Same number of classes being compiled.

So, I played further and tried to find the breaking point of the directory length, for my instance, and I found that while:

C:\abcdefghiklmnop\abcd\

works. this doesn't:

C:\abcdefghiklmnop\abcde\

The extra letter on every path of every class causes it to pass that magical threshold -- which after looking at the the lengths of the two strings that are generated, is somewhere around 2^15.

Any hope of getting a fix before the 1.0 release to the AopC ant task so the compiler will handle a directory passed in, and pass that directly to the standalone compiler? I would assume that I am not the only one who is going to have this issue.

[adrian.brock]

The usual fix for this is to allow a
--SOURCEFILES [file-name]
to be passed in to the compiler.

If the length of the file names is too large it can write them to a temp file
and pass --SOURCEFILES [tmp-file-name]

The other fix is to not use Windows :-)

[bill.burke]

I wonder if the javac target in Ant has the same problem as I based aopc on this code.

I will try and resolve your request...We need to release 1.0 this week as other JBoss Inc. projects are waiting on it so I can't promise anything.

But, this is a serious usability bug, so I'll put cycles into it.

Bill

[squeak]

Bill,

You bring up a good point. I saw your comment about using javac as the basis for the code.

In my same ant task, I also compile the same set of code using javac with no issues. Weird.

I understand about getting 1.0 out --- I can look tonight at the differences and why javac would work and aopc would not.

[squeak]

Bill,

Looking at the source of the javac task -- it appears that Adrian's solution is exactly what they do. When the user wants to fork the process, and the command line is >4096, it outputs it to a temp file, and passes that to the compiler.

When you don't fork via with javac, there is no problem what so ever? Would it be simplier to just not fork the AopC compiler and run it in the same process, like javac?

[kabirkhan]

This will be in the release. If the files portion of the java command is longer than a given number of chars, it creates a temp file as outlined.

I don't know what the limits are, so I have added a maxsrc parameter to the ant task. The default is 1000

[squeak]

Thanks....I really do appreciate it.

Personally, I think following Ant's lead and hardcoding it 4096 as the threshold is fine -- that is the number that POSIX defines as the limit.

[adrian.brock]

Be careful.

Windows is only notionally POSIX compliant.
It defines a POSIX compliant interface, but it does not use it internally (e.g from
the command line/shell) and most WIN32 apis ignore it as well.