8 Replies Latest reply on Oct 20, 2004 8:53 PM by Adrian Brock

    Problem with AopC Ant Task -- cmd too long!

    squeak Newbie

      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?

        • 1. Re: Problem with AopC Ant Task -- cmd too long!
          squeak Newbie

          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.

          • 2. Re: Problem with AopC Ant Task -- cmd too long!
            Adrian Brock Master

            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 :-)

            • 3. Re: Problem with AopC Ant Task -- cmd too long!
              Bill Burke Master

              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

              • 4. Re: Problem with AopC Ant Task -- cmd too long!
                squeak Newbie

                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.

                • 5. Re: Problem with AopC Ant Task -- cmd too long!
                  squeak Newbie

                  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?

                  • 6. Re: Problem with AopC Ant Task -- cmd too long!
                    Kabir Khan Master

                    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

                    • 7. Re: Problem with AopC Ant Task -- cmd too long!
                      squeak Newbie

                      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.

                      • 8. Re: Problem with AopC Ant Task -- cmd too long!
                        Adrian Brock Master

                        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.