Java / Exec problem...

[John Zollinger <jo...@sundog.com>]

Using build 'ant-20000626.zip' on Windows 2000, Sun's JDK 1.3

The java task isn't working for me.  I needed the task to fork, but it seems
that exec holds onto any started task now for piping the stderr, stdout
stuff and does not let go until the task finishes, which isn't really much
of a fork. :-)  The holding on of the exec'd command and piping the output
should be an option I think, rather than the default.

Also (probably because it isn't really forking) my application which uses
Runtime.getRuntime().exec() itself is not working any longer.

Any ideas?

John Zollinger
V.P. Software Engineering, CTO
Sundog Technologies, Inc.
john.zollinger@sundog.com

http://www.sundog.com/

RE: Java / Exec problem...

[Conor MacNeill <co...@m64.com>]

John,

I don't know the history behind the choice of the name 'fork' for this
attribute but I understand the confusion. Really the use of fork just means
that the class is run in a separate VM which is actually invoked in the Exec
code. When a task is exec'd the current VM blocks until the task completes
(Process.waitFor). It is not really to do with the piping of the output.

So, yes, not much of a fork :-( More like "fork and block".

If you read the thread on this list about Multithreading, you will see that
there is some discussion going on about running tasks in separate threads. I
have submitted a patch to make this happen but the final shape of support
for this is still being kicked around.

Cheers
Conor


> -----Original Message-----
> From: John Zollinger [mailto:john.zollinger@sundog.com]
> Sent: Wednesday, 28 June 2000 2:27
> To: Ant-Dev
> Subject: Java / Exec problem...
>
>
> Using build 'ant-20000626.zip' on Windows 2000, Sun's JDK 1.3
>
> The java task isn't working for me.  I needed the task to fork,
> but it seems
> that exec holds onto any started task now for piping the stderr, stdout
> stuff and does not let go until the task finishes, which isn't really much
> of a fork. :-)  The holding on of the exec'd command and piping the output
> should be an option I think, rather than the default.
>
> Also (probably because it isn't really forking) my application which uses
> Runtime.getRuntime().exec() itself is not working any longer.
>
> Any ideas?
>
> John Zollinger
> V.P. Software Engineering, CTO
> Sundog Technologies, Inc.
> john.zollinger@sundog.com
>
> http://www.sundog.com/
>
>