-
Bug
-
Resolution: Won't Fix
-
P2
-
None
-
1.2.0
-
generic
-
generic
DESCRIPTION OF THE PROBLEM:
When Runtime.exec() is called on a console application under
any win32 environment, a console window is created. This only
occurs when the java program has been started using javaw.
If the program was started using java, the title bar of the
spawning window goes crazy and changes its title.
The documentation for java.lang.Process states:
"The created subprocess does not have its own
terminal or console."
This bug goes against documentation that has been in existence
since java 1.0, and we have built a fairly large project
around this long standing specification.
This NEEDS to be fixed (it used to work! can't be
that hard to fix!).
STEPS TO REPRODUCE:
Execute the following code sample using:
>> javaw ExecTest attrib.exe
or
>> javaw ExecTest "attrib.exe /s"
if you want a longer test.
CODE EXAMPLE:
import java.io.*;
/*******************************************************************************
* Demonstrates the Exec bug: When javaw is used with a program that calls exec
* to spawn a console application, a console window appears while the spawned
* app is running. This happens even when ALL pipes are hooked up.<p>
*
* This goes against the exec doco: "The created subprocess does not have its own
* terminal or console." (see API docs for java.lang.Process).<p>
*
* For a good test of this class, execute using:<p>
* <code>javaw ExecTest "attrib.exe /s"</code> <p>
* or remove the /s if you want a very quick demonstration.<p>
* @author Darren McRostie
*/
public class ExecTest
{
public static void main(String[] args)
{
String commandLine = args[0];
Runtime myRunTime = Runtime.getRuntime();
Process proc = null;
try
{
// Spawn process.
proc = myRunTime.exec(commandLine);
// Hook up all streams.
InputStream inStream = proc.getInputStream();
InputStream errStream = proc.getErrorStream();
OutputStream outStream = proc.getOutputStream();
// Loop until the process ends.
while(true)
{
// See if the process has terminated.
try
{
proc.exitValue();
// If we get here, the process has terminated. Stop looping.
break;
}
catch(IllegalThreadStateException e)
{
// If we get here, the process has not terminated.
}
// Suck data out of the pipe.
int bytesAvailable=0;
bytesAvailable = inStream.available();
if(bytesAvailable >0)
inStream.read(new byte[bytesAvailable]);
bytesAvailable = errStream.available();
if(bytesAvailable >0)
errStream.read(new byte[bytesAvailable]);
}
}
catch(java.io.IOException ex)
{
ex.printStackTrace();
}
}
}
ADDITIONAL INFORMATION:
U:\JavaDev>java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
U:\JavaDev>java -fullversion
java full version "1.3beta-O"
FINAL NOTE:
We have build a project around this and we NEED it to be fixed.
The exec method has worked correctly and been documented
correctly for a long time. The behaviour of JDK1.3 should NOT
deviate from this behaviour at all! If a new system for
external process control is needed (and it probably is) it
should be provided as an extra component and this bug
should be fixed to ensure backward compatibility.
(Review ID: 96468)
======================================================================
When Runtime.exec() is called on a console application under
any win32 environment, a console window is created. This only
occurs when the java program has been started using javaw.
If the program was started using java, the title bar of the
spawning window goes crazy and changes its title.
The documentation for java.lang.Process states:
"The created subprocess does not have its own
terminal or console."
This bug goes against documentation that has been in existence
since java 1.0, and we have built a fairly large project
around this long standing specification.
This NEEDS to be fixed (it used to work! can't be
that hard to fix!).
STEPS TO REPRODUCE:
Execute the following code sample using:
>> javaw ExecTest attrib.exe
or
>> javaw ExecTest "attrib.exe /s"
if you want a longer test.
CODE EXAMPLE:
import java.io.*;
/*******************************************************************************
* Demonstrates the Exec bug: When javaw is used with a program that calls exec
* to spawn a console application, a console window appears while the spawned
* app is running. This happens even when ALL pipes are hooked up.<p>
*
* This goes against the exec doco: "The created subprocess does not have its own
* terminal or console." (see API docs for java.lang.Process).<p>
*
* For a good test of this class, execute using:<p>
* <code>javaw ExecTest "attrib.exe /s"</code> <p>
* or remove the /s if you want a very quick demonstration.<p>
* @author Darren McRostie
*/
public class ExecTest
{
public static void main(String[] args)
{
String commandLine = args[0];
Runtime myRunTime = Runtime.getRuntime();
Process proc = null;
try
{
// Spawn process.
proc = myRunTime.exec(commandLine);
// Hook up all streams.
InputStream inStream = proc.getInputStream();
InputStream errStream = proc.getErrorStream();
OutputStream outStream = proc.getOutputStream();
// Loop until the process ends.
while(true)
{
// See if the process has terminated.
try
{
proc.exitValue();
// If we get here, the process has terminated. Stop looping.
break;
}
catch(IllegalThreadStateException e)
{
// If we get here, the process has not terminated.
}
// Suck data out of the pipe.
int bytesAvailable=0;
bytesAvailable = inStream.available();
if(bytesAvailable >0)
inStream.read(new byte[bytesAvailable]);
bytesAvailable = errStream.available();
if(bytesAvailable >0)
errStream.read(new byte[bytesAvailable]);
}
}
catch(java.io.IOException ex)
{
ex.printStackTrace();
}
}
}
ADDITIONAL INFORMATION:
U:\JavaDev>java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)
U:\JavaDev>java -fullversion
java full version "1.3beta-O"
FINAL NOTE:
We have build a project around this and we NEED it to be fixed.
The exec method has worked correctly and been documented
correctly for a long time. The behaviour of JDK1.3 should NOT
deviate from this behaviour at all! If a new system for
external process control is needed (and it probably is) it
should be provided as an extra component and this bug
should be fixed to ensure backward compatibility.
(Review ID: 96468)
======================================================================
- relates to
-
JDK-5005176 (process) Can't run 16-bit DOS programs (.com files)
-
- Closed
-