The semantics of external process is noy clearly defined in Java spec. 
Many of the external process related bugs are caused by this problem. 
Here is a couple of examples of how the semantic problem is:

1.When we create a process and don't give environment variables, will the
  child process inherit those of parent process? See bug 4064912

2.When we create a process, the process will be detached from Java process.
  But for win16 program, we can not run a 16-bit process in detached mode.
  Because the 16 prog must run inside a 32-bit virtual machine process. 
  In detached mode, there is no such process to reside in. On win32, the
  detached process is supposed to have its own console.
  What shall we do? See bug 4079419.

3.By default, the child process's stdout and stderr are redirected to parent
  process. If parent process does not read the pipe, the child process will
  block when pipe is full. See bug  4062587

4.When we create a child process, will the child process inherits the file
  handles or other system resources from parent. See bug 4093815

5.The current implementation of process code assume unix syntax and semantics.
  Which will be almost impossible on mac, where there is not concept of 
  stdio, console etc.

6.On unix, it is shell(the parent process) do the command line parsing. On  
  win32, the parsing is done by both parent process and child process CRT. 
  See bug 4064116

7.How should we handle(atually define) the virtual machine process? If we
  run a Java program, the Java main() does not return anything. The exitcode 
  is the vm exit code. Will that be  customer  enough?

8.How should we handle program does not use main() function, like native
  windows app. The win32 let parent process to specify the window size, 
  location, maybe minimized or maximized. But the current syntax prevent
  user from having full control of its child process.

The bottom line is the process is an external concept to Java. How should we
address the semantic difference? The current implementation uses the unix semantics, but it brreaks in many different ways.
Posted Date : 2005-08-18 18:12:11.0

Since the spec does not give the semantic definition about the java.lang.Process, adding some additional javadoc in Process.java will
help user with using the Process API. It should not affect the current spec.

  xxxxx@xxxxx   1998-02-13

This is all true. The JLS is no longer concerned with library issues like this,
but our libraries should address what (if any) concept of external process 
can portably be supported.

  xxxxx@xxxxx   2000-02-02

This is a library issue, not runtime bug.

  xxxxx@xxxxx   2000-06-29

>1.When we create a process and don't give environment variables, will the
>  child process inherit those of parent process? See bug 4064912

Further support for environment variables was added in 1.5.  

I think it should be system-dependent what happens if null is passed as
the child environment. 

2.When we create a process, the process will be detached from Java process.
>  But for win16 program, we can not run a 16-bit process in detached mode.
>  Because the 16 prog must run inside a 32-bit virtual machine process.
>  In detached mode, there is no such process to reside in. On win32, the
>  detached process is supposed to have its own console.
>  What shall we do? See bug 4079419.

Supporting win16 programs is surprisingly difficult. Since win64
is droppping support for such programs, adding such support is becoming
less important.  I worked on getting a fix into Tiger, but failed.

3.By default, the child process's stdout and stderr are redirected to parent
>  process. If parent process does not read the pipe, the child process will
>  block when pipe is full. See bug  4062587

There is a jplan feature to do better io redirection.    
This is very tricky.  From perlipc(1)

     Here's an example of using open2():

         use FileHandle;
         use IPC::Open2;
         $pid = open2(*Reader, *Writer, "cat -u -n" );
         print Writer "stuff\n";
         $got = <Reader>;

     The problem with this is that Unix buffering is really going
     to ruin your day.  Even though your "Writer" filehandle is
     auto-flushed, and the process on the other end will get your
     data in a timely manner, you can't usually do anything to
     force it to give it back to you in a similarly quick
     fashion.  In this case, we could, because we gave cat a -u
     flag to make it unbuffered.  But very few Unix commands are
     designed to operate over pipes, so this seldom works unless
     you yourself wrote the program on the other end of the
     double-ended pipe.

I have some ideas for a less hostile interface for running processes
in synchronous mode, as many users want.  It is hard to design well.


8.How should we handle program does not use main() function, like native
>  windows app. The win32 let parent process to specify the window size,
>  location, maybe minimized or maximized. But the current syntax prevent
>  user from having full control of its child process.

To do system-specific things, you need to use a system-specific helper
program, such as start.exe or xterm.


  xxxxx@xxxxx   2005-03-29 08:18:17 GMT

This is a serious flaw. I understand that we
are dealing with a OS specific concepts but not
having a clear spec of a process limits developers.
I've seen on the newsgroups, the developer database
and other places at least a dozen of issues related
to using exec specially under Win95/WinNT.
This is keeping me from moving my application to
run using Java in Win95. Hope this bug gets fixed
and not swept under the rug to resurface as 
a design defect.
 

I agree.  I would like to see detailed specifications on how to use
runtime.exec.  I found out many of the problems listed the hard way.

Bug 4188007 (which was merged into this one) is the showstopper for our
migration from 1.1.7 to 1.2, which we badly need to do for other reasons.  Our
application is a game which uses a Java GUI as a front-end to a series of child
processes spawned with Runtime.exec(), most of our users run Win32, and it is
not an option to have console windows constantly popping up in the user's face.
 1.1.7 got this right, but 1.2 broke it.  PLEASE fix it again.

I agree with jaffray's post.
This is the showstopper for our 
migration from 1.1.7 to 1.2 too.
We also cannot accept console
windows popping up in our user's face.
Please fix this bug.

This is yet another reason to go back to 1.1.8
after we spent a bunch of time migrating to 1.2.
Unfortunately, your neglect is making us look
bad to our bosses, and they are REALLY second
guessing the use of Java.

As the description of class Process says: 
"The created subprocess does not have
its own terminal or console. All its 
standard io (i.e. stdin, stdout, stderr)
operations will be redirected to the 
parent process through three streams ..."
We have based a product on this promise!
Since we are adding 3D visualisation as well
we are in a real bind, we can't stay with 1.1.7
and we cant go to 1.2.2.
I expect Sun to honour their own specifications.
Especially for something in the lang package.
Check out bug#4244515 which describes the
problem well.

The solution which I prefer is to use runtime.exec() or a socket connection to
a daemon
merely to spawn a launcher.
The target program is then launched in a dis-connected fashion and the java
application
connects to sockets which permit communication with the target program. This
works
extremely well on UNIX and on windows and allows me to define my own,
consistant, semantics.
[And no, I can't provide the launcher code ;-( Surfice to say that Steven's
Advanced 
Programming in the Unix Enviroment is a good source for information about this
type of technique.]
Joel Crisp

This bug is severely exacerbated by the fact that the basic
semantics of spawning a separate process is extremely bizarre
on Windows (Win16 is different to Win32, and the various Win32
variants are all different to each other!)  The simplest way to
"work around" this is to avoid those platforms altogether, but
that isn't exactly what most people would describe as feasable...

I don't know if it is just me... But this looks like a very
severe problem...
It is symptomatic of the current state of Java. It needs
a lot more polishing... Java works, but it isn't always very
pretty...
What's the point of having nice GUI like Swing if you are
not fixing bugs like this one???

I agree with previous comments about this being a show-stopper.
Our application looks great under 1.1.7, but they are not going to
accept this console box appearing.  However, we actually want to get 
to 1.2 (or 1.3) to take advantage of other fixes and improvements, 
but can't if this is the behavior we're going to be getting.  

It's an <em>Operating System</em> fault.  You can't fix it without
native code.  Don't moan to Sun about the inconsistency of
Windows when the blame for that is definitely most appropriately
laid at Microsoft's door.  (The precise behaviour of
<tt>CreateProcess</tt>
varies between various versions of the Win32 API, and the
resulting problems afflict not just Java but many other programming
environments too.)

This is another reason for me to delay moving to 1.2.

We agree this a very serious bug for us. We can't release 
our management console. This is a show stopper.

I couldn't care less whose "fault" it is.  I'm not a Windows
programmer, I'd love to never touch another Windows box in
my life, I'd love to never deal with another Microsoft API,
but the fact is that I have to ship code that works under
Windows.

There is an obvious correct behavior here, one which is
possible to implement (as 1.1.7 demonstrates), and 1.2 and
later are simply broken.  This is a BUG.  It's a SERIOUS
bug, one that completely and unavoidably hoses anyone using
System.exec() in user-visible code under Win95/98. 
Connecting two processes is not a frill, it is BASIC
FUNCTIONALITY, and there is currently NO WAY to do it in
Java under Windows without the unacceptable side effect of a
console window.

It's a showstopper for me.  Several people have written here
that it's a showstopper for them.  Several people have seen
my address here and written to me privately because they're
in the same situation and hoped maybe I'd found a workaround
in the YEAR since Sun broke System.exec() and had the bug
reported to them.  No luck.

In the meantime, a substantial number of our users
experience crashes because of known resource leaks in 1.1. 
These are fixed in 1.2, but we can't use 1.2.  We have
frustrated customers, we are getting bad press, and we are
powerless to do anything about it until either Sun provides
a fix or we rewrite all 20K lines of interface code to use
something other than Java + AWT/Swing.  I am getting VERY
close to doing the latter; it's completely ridiculous to
have to do such a thing, but this is a ridiculous situation,
and at some point we HAVE to stop waiting for Sun and
provide something more stable than what we're currently
shipping.  I am regretting having put myself at Sun's mercy
by implementing this in Java in the first place.

Why hasn't this been fixed, anyway?  The proper behavior
already existed in a previous version, can it really be that
difficult of a fix?

Just another deeply frustrated former Java advocate...

I am *SO* disappointed with the latest offering from Sun.  JSDK 1.3 RC1 still does not address this problem.  
It is not a hard problem to fix.

For any of those who are interested, I have written a small C program that I use as a loader to spawn 
console applications from Java without the console window appearing.  I am happy to forward the code to 
any who are interested.  I would be *VERY* happy if Sun had a look at it - it isn't that difficult to use 
CreateProcess to do this (and have pipes re-directed under NT, 98, 95).

NOTE: It appears that Sun has made a new bug entry that relates purely to the exec console window 
problem.  See bug 4244515.  I suggest all those who voted for this entry also vote for this bug.

This bug has been an irritant for over
2 years.  If you are not concerned, you should be.
Fix it.

I'd certainly add my feelings to this - what a pain! 
I spent ages trying to get op sys commands to work from 
Runtime.exec() until I finally found a few choice articles 
in forums and the like. (I needed to run XCOPY and 
DELTREE). Got it all working on Win 95 under JRE 1.2, moved 
it to Win NT and - bang! Irritating little windows popping 
up all over the place, or the system hanging as it tries to 
do readLine() method. Trying to find a solution that is 
guaranteed to work on both 95 and NT has been dreadful - 
and it shouldn't be like that, JavaSoft. A developer should 
be able to look at a class spec and know what it is going 
to do if Java claims to be Write Once Run Anywhere.
In the end, I had to borrow a Visual Basic EXE written by a 
friend which spawns a BAT file nice & quietly in the 
background - and it works fine on both 95 and NT. I'm sure 
it can't be that difficult to fix this bug.......

Please fix the concole window bug.  Pretty please, with 
sugar on top and a cherry?

This is a show stopper for my product too. We simply can't
release with 1.2/1.3 until this problem is fixed. Its not an
option to have DOS windows popping up all over the place.

I hate to say it but Visual Basic looks better and better at the moment.

I would like also express my openion on this "system 
dependent issues". "System dependent" they should be for 
developers of the JVMs, not for the JVM users.
One of the way to guarantee it for the MS Windows*** 
systems inconsistences would be developing different 
versions of JVM for say Windows95, 98, NT...
It was said, that promise should be kept.
...
And we all know what promise helped Java to be The Java!
Brake it and you are..., no, we all are BIG loosers. 

An interesting note on that: If you look at the Java IDE 
provided by the fabulous text editor Textpad 
(http://www.textpad.com/) you will see that there are no 
console boxes popping up. Does anyone have an idea how they 
do it ?

I have two workarounds which are both not perfect but could 
be at least a starting point.

The first workaround is based on the windows scripting 
host, the second one one the usage of javaw and a GUI Mode 
C++ program

<h1>Environment</h1>

<ul>
  <li><b>Operating System</b>: Windows NT 4.0, Service Pack 
5
  <li><b>Java:</b>: Java 1.2.2 from Sun (version 006 I 
believe)
</ul>

<h1>Workaround 1: Windows Scripting host</h1>

The Windows Scripting Host (WSH) ships with some versions 
of windows (Windows 98 at least), it is freely downloadable
from Microsoft's Web Site (try 
http://msdn.microsoft.com/scripting/). WSH is very similar 
(or maybe even the same)
as Visual Basic Script. I think it was intented to replace 
the old DOS like batch files with a more powerful and
standardize language, but most people (like me) still 
create .BAT programs... <p>

Anyway, WSH provides the possibility to execute programs 
hiding the DOS console. Here is some example code running 
the
class "test.class".

<h2>Example</h2>

<pre>
dim WSHShell
set WSHShell = CreateObject( "WScript.Shell" )
WSHShell.Run "c:\jdk12~1.2\bin\java -cp .;c:\jdk1.2.2\lib 
test", 0, true
</pre>

<h2>Notes</h2>
<ul>
  <li>you should specify the classpath via the -cp option.
  <li>the call only worked when specifying the path in 8.3 
format (I could also be wrong on this)
  <li>the second parameter for WSHShell.Run (0) 
means "Hides the window and activates another window."
  <li>the third parameter for WSHShell.Run (true) means 
that the script will wait for the program to be completed
  	  before continuing execution
</ul>
<p>

<h2>Problems</h2>
<ul>
  <li>some swing components did not show at all; I think 
this is a problem with heavyweight components, though some
      of them show. I haven't digged into that further 
because I chose Workaround 2
</ul>



<h1>Workaround 2: javaw/c++</h1>

javaw is used to call the VM, the external program is 
written in C++; The C++ compiler used is the free Borland 
C++
compiler 5.5 
(http://www.borland.com/bcppbuilder/freecompiler), but this 
should also work with other compilers. <p>

Windows programs can operate in two different modes which I 
call the "console mode" and the "GUI mode" (I do not know
if these are the "official" terms, but I'll stick to them 
in here).

<h2>Console mode</h2>

The console mode is more DOS oriented and will pop up a DOS 
box when executing the program). The main method for the
console mode is the famous int main() method: <br>

<pre>
int main(int argc, char *argv[])
{
...
}
</pre>

I will not go into details of this mode, as we are choosing 
the GUI mode.

<p>

<h2>GUI mode</h2>

The GUI mode does NOT pop up a DOS box.


<h3>main method</h3>

The main method here is called WinMain: <br>

<pre>
#include <windows.h>

int WINAPI WinMain(HINSTANCE instance, HINSTANCE 
prev_instance, char* command_line, int show_command)
{
...
}
</pre>
<p>



<h3>make file</h3>

For creating the executable you might have to use a special 
option for the compiler like <b>-W</b> for the Borland
Compiler (BCC).

Here is a sample BCC make file:


<pre>
CPP=bcc32
DLLFLAG=-WD
OFLAG=-o

WININCLUDE= -Ic:/winapp/bcc55/include -
Ic:/jdk1.2.2/include -Ic:/jdk1.2.2/include/win32


dos:  \
	winsab.exe

winjava.exe:
	$(CPP) $(WININCLUDE) $(LINKER) $(OUTPUT) -W 
winjava.cpp
</pre>



<h2>Notes</h2>
<ul>
  <li>Using C or C++ another option is to use JNI (Java 
Native Interface); I have explored this and experienced 
tough
  	  memory problems which I firstly related to JNI 
but know I'm pretty sure that the 

Oops - here is a plain text version of my previous entry

---------


I have two workarounds which are both not perfect but could 
be at least a starting point. The first workaround is based 
on the windows scripting host, the second one one the usage 
of javaw and a GUI Mode C++ program 
Environment
Operating System: Windows NT 4.0, Service Pack 5 
Java:: Java 1.2.2 from Sun (version 006 I believe) 
Workaround 1: Windows Scripting host
The Windows Scripting Host (WSH) ships with some versions 
of windows (Windows 98 at least), it is freely downloadable 
from Microsoft's Web Site (try 
http://msdn.microsoft.com/scripting/). WSH is very similar 
(or maybe even the same) as Visual Basic Script. I think it 
was intented to replace the old DOS like batch files with a 
more powerful and standardize language, but most people 
(like me) still create .BAT programs... 
Anyway, WSH provides the possibility to execute programs 
hiding the DOS console. Here is some example code running 
the class "test.class". 

Example
dim WSHShell
set WSHShell = CreateObject( "WScript.Shell" )
WSHShell.Run "c:\jdk12~1.2\bin\java -cp .;c:\jdk1.2.2\lib 
test", 0, true

Notes
you should specify the classpath via the -cp option. 
the call only worked when specifying the path in 8.3 format 
(I could also be wrong on this) 
the second parameter for WSHShell.Run (0) means "Hides the 
window and activates another window." 
the third parameter for WSHShell.Run (true) means that the 
script will wait for the program to be completed before 
continuing execution 

Problems
some swing components did not show at all; I think this is 
a problem with heavyweight components, though some of them 
show. I haven't digged into that further because I chose 
Workaround 2 
Workaround 2: javaw/c++
javaw is used to call the VM, the external program is 
written in C++; The C++ compiler used is the free Borland 
C++ compiler 5.5 
(http://www.borland.com/bcppbuilder/freecompiler), but this 
should also work with other compilers. 
Windows programs can operate in two different modes which I 
call the "console mode" and the "GUI mode" (I do not know 
if these are the "official" terms, but I'll stick to them 
in here). 

Console mode
The console mode is more DOS oriented and will pop up a DOS 
box when executing the program). The main method for the 
console mode is the famous int main() method: 

int main(int argc, char *argv[])
{
...
}

I will not go into details of this mode, as we are choosing 
the GUI mode. 

GUI mode
The GUI mode does NOT pop up a DOS box. 
main method
The main method here is called WinMain: 

#include <windows.h>

int WINAPI WinMain(HINSTANCE instance, HINSTANCE 
prev_instance, char* command_line, int show_command)
{
...
}


make file
For creating the executable you might have to use a special 
option for the compiler like -W for the Borland Compiler 
(BCC). Here is a sample BCC make file: 
CPP=bcc32
DLLFLAG=-WD
OFLAG=-o

WININCLUDE= -Ic:/winapp/bcc55/include -
Ic:/jdk1.2.2/include -Ic:/jdk1.2.2/include/win32


dos:  \
	winsab.exe

winjava.exe:
	$(CPP) $(WININCLUDE) $(LINKER) $(OUTPUT) -W 
winjava.cpp

Notes
Using C or C++ another option is to use JNI (Java Native 
Interface); I have explored this and experienced tough 
memory problems which I firstly related to JNI but know I'm 
pretty sure that the problems lie in the way may C++ 
program is written - so if you are using C or C++ you could 
also use JNI 
Problems
I could not manage to read command line parameters; to be 
exact, I did manage to do so, but that caused access 
violations, so that I decided to use plain text files for 
input and output. 
As the file names are fixed in both the calling java 
application and the called C++ program, this kind of 
implementation will probably only work when only one 
instance of the java program is running (which is the case 
in my scenario) 

Does anyone from Sun know when these issues will be addressed? or if they are even being actively looked at?

Sun doesn't seem to work on any of these bugs, no matter 
how many votes they get.

Actually, I would prefer that this whole area be 
readdressed with an extension API or something similar.  
The way it is now it is almost useless.

Also, it would be nice/useful to have Runtime.exec() behave in standard mode like a Unix
shell or fork(). Ie, just like a shell "cmd &", be able to execute an external process in the
background without having to worry about reading/writing from/to the process stdout/stdin.

We would love to have a short term solution within the scope
of the current API definition.

The JVM locks up under Win98 - even under ideal conditions
(3 independent threads working with I/O streams of the
external process).

Sun please contact me via bht at actrix.gen.nz for a
complete testcase and workaround concept.

I could point you to someone at Sun who has experience with
the same issue as we are facing and who has suggested a very
interesting solution.

Thanks

Ok, this is an OS specific problem. But, JVM should be able 
to deal with this problem because Java concept is "Write 
Once Run Anywhere".
I propose, it should has a runner server which writen in 
specific platform and JVM make a standard to communicate 
with it for request process execution.

With JDK1.4.0_01 on Windows 2000 - I don't see "Console
Windows popping up when a process is spawned from Java with
Runtime.exec(). Is this bug fixed for all Windows platforms?

I don't see this problem in 1.4.0_01. Has this been fixed in
1.4.0_01? If so is it fixed for all Windows platforms
(specifically Windows 2000, Windows Me, Windows XP)??

Sorry for double posting but I think this is the right place for 
my problem. 
Yes, DOS consoles are ugly and when they are black and 
blank slightly mystifying until you realize that they respond 
to ^C. This allows the user to interrupt a possibly very long 
execution. The subprocess (not written by me) and my java 
application then work together to tidy up. This was fine 
under 1.3.1+ but is now broken under 1.4+. Process.destroy
() does not kill the subprocess under any jvm. I need to have 
the interrupt facility afforded by the console window in 
1.3.1+-. 
I now run javaw.exe and capture the sysout into a JTextArea 
whereas previously I ran java.exe and the sysout just was 
written onto the console. In this latter case pressing ^C just 
made the whole thing vanish, whereas now with javaw it all 
behaves nicely (under 1.3.1+-).
Please can JavaSoft make the console window optional or 
give me some other way of saying ^C to my subprocess? 

I've said before what the problem is: the whole underlying OS 
API that Runtime.exec() builds on is broken under Windows. 
By broken, I mean inconsistent even between different 
releases of what is supposedly the same OS.  Unlike on Unix 
where there is a simple definition of what Runtime.exec() 
does (feed the arguments into a fork()/exec() with some bog 
standard work to fix up the pipes), on Windows you have to 
do some really deep voodoo to make things work.

The key problem is that Microsoft, in their role as OS vendor, 
did not really have a solid definition of a process for their 
DOS-based OSes (including 95, 98 and ME IIRC).  And even 
on NT, there's still problems because you're supposed to 
invoke processes differently if they are GUI apps or console 
programs.  And I think there are more subtleties than that.

IMHO, if you need Runtime.exec(), don't use Windows.  This 
is because process control is the part of Windows that sucks 
most of all, bar none.  If you need Runtime.exec(), use Linux 
or Solaris or some other Unix.  End Of Story.

Javasoft people, could you please close this bug off as being 
fundamentally unfixable?

It is even worse. When the Java is closed, the exec'ed 
program will continue to run.

Suppose you Runtime.exec("CMD /c del *.txt"), then you 
create some more files. The CMD is hanged. When the JVM 
exits, the CMD will continue, and will DELETE ALL THE NEWLY 
CREATED FILES.

Nice, ha?

dkf suggests java.lang.Process users should abandon 
Windows. That would make my users apoplectic. Process 
should be made to work with windows. My (console) 
processes work very well from inside batch files where I can 
set environment variables etc. Detecting the echo of an 
>Exit statement tells me that the process has truly ended. 

I know your users would hate to abandon Windows.  I also 
know that there is a stinking big impedance between the way 
all Unix systems and Win32 regard processes.  This is just the 
way it is.  Working around it requires, at a minimum, knowing 
which Win subsystem a process/app will be running in, since 
some work properly, some fail unless sacrifice the chicken in a 
black satanic mass... err... pass the right flags to the 
CreateProcess() call, and some fail to behave usefully under 
all circumstances.

If you can stick to using Win32 console apps, then it works.  
But Win32 GUI subsystem apps (e.g. javaw.exe vs. java.exe) 
disconnect themselves automatically IIRC, and Win16 and 
DOS apps are horrible.  I don't even know of anyone who 
knows of fully reliable ways to work around this sort of 
problem from C++, where you've got direct access to the 
whole Win32 API.  And I believe that the termination of 
running apps is even nastier...

I suppose it would be possible to describe how the exec() 
and various Process methods map onto the low level, with a 
warning that the mapping is not guaranteed to remain the 
same between versions.  That would at least let people have 
a go at spotting where their bugs actually are.

Sun *can't* fix the bug, and MS don't care.  It's even 
possible that they can't fix the problems either.  That's Life.

If this bug will ever be fixed... there should also be an
API to redirect process stdout/stderr, including redirecting
them on the same stream. This is possible both under
linux/unix and windows (in windows using cmd). using a
couple of threads to read the streams doesn't lead to the
same result, as the interleaving between stderr and stdout
becomes less thin grained.

You could just use a helper shell-script to handle that (you're 
already not pure java as you're using the Process API so 
doing something platform-specific shouldn't be shameful) 
perhaps like this:

  #! /bin/sh
  # Simple wrapper script to join stdout and stderr streams
  exec "%@" 2>&1

My other point is that you can use NIO when reading the 
input so you only need a single thread to read all the output 
from the process. You can even use one thread for several 
processes...

Item 1 the answer is yes.
Item 2 no longer matters, only win32 should be addressed.
Item 3 is perfectly OK as long as it is documented.
Item 4 the answer is no.
Item 5 no longer matters, because of os x where there is a 
console available.
Item 6 is irrelevent and an implementation detail of no 
concern.
Item 7 the System.exit(int) should be the exit code, and yes, 
it should be good enough as long as the behavior of the VM 
and it's exit codes are documented.
Item 8 is not important, IMHO.

This should be made an RFE.

-G

If you want your program to close after a runtime.exec in 
windows you can execute a .PIF file.  You set this up by 
editing the properties of a PIF you copy from the _default.pif 
in the windows directory. 

I agree that this is not a bug, but I'm not sure that it is 
necessarily an RFE either.  It's more of a "Oh, that's too 
bad" caused by a specific underlying API in one 
(unfortunately common) OS that's just plain nasty.

If you *really* need Runtime.exec() for doing things like 
running multiple Java processes, you probably don't  
want to run on top of Windows of any version.  Borrow 
a nickel off someone and get a proper OS (to misquote 
Dilbert) since the basic problem isn't going away.

One minor point though: Point 6 about where 
command lines are parsed isn't irrelevant, but it is 
unfixable since different Windows executables use 
different argument parsers.  Current best practice is to 
make the quoting generator do the right thing for the 
default VC6 runtime's parser; whether or not it is best, 
it is at least common and less broken than many of the 
alternatives.

Ok, there is now a consensus:

Item 1 the answer is yes.  Child Process is to inherit the Parent processes environment variables.
Item 2 no longer matters, only win32 should be addressed.
Item 3 is perfectly OK as long as it is documented.  The pipe should be read by the parent.  An alternative exec that throws output away would be OK as well.
Item 4 the answer is no.  The child should inherit no file handles or system resources from the parent.
Item 5 no longer matters, because of os x where there is a console available.
Item 6 (dkf ) ...current best practice is to 
make the quoting generator do the right thing for the 
default VC6 runtime's parser; whether or not it is best, 
it is at least common and less broken than many of the 
alternatives.
Item 7 the System.exit(int) should be the exit code, and yes, it should be good enough as long as the behavior of the VM and it's exit codes are documented.
Item 8 is not important, IMHO.  If they need special window positioning, etc, the user can resize/drag things arround, I think we are far more concerned with headless usage.

Please add this to the JLS.

What did Eclipse do to run external processes and have them synchronized so cleanly in its own Java-based console?
Why is it possible in the Eclipse environment and not in the base JRE?

Time to collaborate with Eclipse developpers, to see if some of the support code they implemented (possibly with platform-specific helper native JNI) can be imported as a already working model.

Look at how Eclipse can create external processes (even non Java processes, for example Windows build commands like invoking C compilers or external make tools) so fast, and make them run without any back command window to appear.

They seem to have extended the process model to allow specifying which handles are inherited, and a native JNI helper is managing the cleanup of external resources like file handles on both Windows and Unix/Linux.

Yes, there aer possibly race conditions, still unsolved in Eclipse, causing it to hang for some long period, but this support is getting ever better, notably because Eclipse supports the JVMDI/JVMTI interfaces to control many things in its own JVM or in the child VM it creates (for running apps with different JVM versions).

Is that support part of the native SWT and native SWT GDIP support ?

For item 4, I suggest that handles may be inheritable, is this is specified as a property. The default would be to not inherit it, but why not having an interface that allows registering a handle or ressources to a list of interested libraries (= listeners) that would keep the reference to resources they want to keep in inherited processes. These listeners could even perform security checks, to see if the target process that is about to be created should be granted access to the shared handle.

This means a two-phase commit like procedure when creating processes, i.e. a "Prepare to Run" phase, where the necessary handles will be granted, or dropped from the parent or child references (through restriction properties), or duplicated (possibly with different access rights for the child).

With "interested libraries", I mean some process factory classes, which may also be implemented as part of class loaders (for managing the security), and at least a default factory shipped with the JVM (other process factories may be provided by third-party libraries implementing their class loaders).

During phase 2, the VM would look at the list of resources, with the indicated properties, and would then decide about which handle to keep. It would then create the child process, perform the necessary cleanup according to the listed constraints, and then would run it.

Various things can be managed this way: file handles, consoles (stdio), memory mappings, communication handles (sockets, pipes, event queues...), native window handles (may require conversion using some native API implemented in the system-specific helper, due to the native system security policy).

For some platform, a secure system to transmit the shared handles may require a helper app provided with the VM and that will allow communication between the parent and the prepared child (for example using a localhost socket, something that is easier to secure as it allows cross-process isolation and the protocol can be strictly controled on both sides).

So the default policy for all handles is to keep them private for the parent, but other policies aer possible, including transfering the full control to the child (after initial sharing: the parent is supposed to clean up its existing control very fast to let the child process perform all what it wants with those transfered system resources).

Java programmers would be first interested in having fine control on the first phase. The second phase would be fully automated, and would be responsible of just retuning a status to the process creation method caller (status or exception), or progress information (through callbacks during phase 1).

The Runtime.exec() would just be a shortcut, but what it does should be a documented two-phase system. Pahse 1 may be aribtrarily complex, using the Process class specification. As long as its run method is not invoked, the process object remains in phase 1, so multiple settings are possible. When the run method is invoked, the preparation is supposed to be OK, and will either succeed or cause the process to die definitely without running (the Process object will be in a post-mortem state during which resource cleanup may be performed by the parent, or indirectly by finalizers from the GC).

Test

I know it's a low priority, but please give this bug a little love.

4 years since the last post on this.  Please?  11 years is a long time to wait.

<h1>prikol</h1>

<a href="http://google.com">asd</a>

http://google.com

Is there overlap here with JSR 121?