Java Exec Problem with Unzip

[O.B.]

I'm having an odd problem in trying to get the "unzip" utility to
execute without locking up the Java process. In the code below, the
runtime.exec command successfully executes but the process.wairFor()
loop locks up about halfway through the zip file extraction process.

Help?

public static void installJboss(String installDir) {
//
// Only copy files if JBoss not installed. Check this
// by searching for jbossDir/bin/run.jar
//
String result = "";
if ( !(new File(installDir + "/bin/run.jar")).exists() ) {
//
// Extract files
//
File jbossDir = new File(installDir);
if ( !jbossDir.exists()) {
jbossDir.mkdirs();
}
String command =
"utilities/bin/unzip.exe utilities/archives/jboss-4.0.2.zip -d "
+ jbossDir.getAbsolutePath();
Runtime runtime = Runtime.getRuntime();
try {
Process process = runtime.exec(command);
process.waitFor();
if (0 != process.exitValue()) {
result = "Failed to execute: " + command;
}
} catch (InterruptedException e) {
// Ignore
} catch (IOException e) {
result = "Failed to execute: " + command;
}
}
return result;
}

 

[Chris Smith]

I'm having an odd problem in trying to get the "unzip" utility to
execute without locking up the Java process. In the code below, the
runtime.exec command successfully executes but the process.wairFor()
loop locks up about halfway through the zip file extraction process.

Chances are the zip process is blocking trying to write to standard
output. Try adding this after you run the process:

final InputStream in = process.getInputStream();
new Thread(new Runnable() {
public void run()
{
try
{
while (in.read() != -1);
}
catch (IOException e)
{
logTheError(e);
}
}
}).start();


--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

Chances are the zip process is blocking trying to write to standard
output. Try adding this after you run the process:

final InputStream in = process.getInputStream();
new Thread(new Runnable() {
public void run()
{
try
{
while (in.read() != -1);
}
catch (IOException e)
{
logTheError(e);
}
}
}).start();

Chris is correct, for more details, see
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Process.html

<quote>
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 (getOutputStream(),
getInputStream(), getErrorStream()). The parent process uses these streams
to feed input to and get output from the subprocess. Because some native
platforms only provide limited buffer size for standard input and output
streams, failure to promptly write the input stream or read the output
stream of the subprocess may cause the subprocess to block, and even
deadlock.
</quote>

- Oliver

 

[O.B.]

I'm having an odd problem in trying to get the "unzip" utility to
execute without locking up the Java process. In the code below, the
runtime.exec command successfully executes but the process.wairFor()
loop locks up about halfway through the zip file extraction process.

Help?

public static void installJboss(String installDir) {
//
// Only copy files if JBoss not installed. Check this
// by searching for jbossDir/bin/run.jar
//
String result = "";
if ( !(new File(installDir + "/bin/run.jar")).exists() ) {
//
// Extract files
//
File jbossDir = new File(installDir);
if ( !jbossDir.exists()) {
jbossDir.mkdirs();
}
String command =
"utilities/bin/unzip.exe utilities/archives/jboss-4.0.2.zip -d "
+ jbossDir.getAbsolutePath();
Runtime runtime = Runtime.getRuntime();
try {
Process process = runtime.exec(command);
process.waitFor();
if (0 != process.exitValue()) {
result = "Failed to execute: " + command;
}
} catch (InterruptedException e) {
// Ignore
} catch (IOException e) {
result = "Failed to execute: " + command;
}
}
return result;
}

Figured it out. It was a problem with the stdout buffer getting filled.
When I run unzip in quiet mode, the program finishes without glitches.

Someone pointed out java.util.zip.ZipFile and from what I have gathered
so far, it is a better solution.

 

[Mike Schilling]

Chances are the zip process is blocking trying to write to standard
output. Try adding this after you run the process:

final InputStream in = process.getInputStream();
new Thread(new Runnable() {
public void run()
{
try
{
while (in.read() != -1);
}
catch (IOException e)
{
logTheError(e);
}
}
}).start();

Or it could be writing to standard error, so you really should do the same
with getErrorStream(), though that requires creating another thread to empty
that stream.

 

[Tony Morris]

I'm having an odd problem in trying to get the "unzip" utility to
execute without locking up the Java process. In the code below, the
runtime.exec command successfully executes but the process.wairFor()
loop locks up about halfway through the zip file extraction process.

Why aren't you using the java.util.zip package?

--
Tony Morris
http://tmorris.net/

Java Questions and Answers
http://jqa.tmorris.net/

 

[Tony Morris]

Java.util.zip has one big drawback. It only understands a few of the
possible compression algorithms. It pretty well can only deal with
zips created by itself. If the zip came from the outside world, you
need to exec something like wzunzip or pkunzip.

WTF? Got any proof? I call bullshit. The alternative being that my eyes have
been deceiving me for years, and the API specification implementation that
I've been working on is nothing more than a result of my delusional state.
You might be referring to zip format extensions created by applications such
as Winzip?

--
Tony Morris
http://tmorris.net/

Java Questions and Answers
http://jqa.tmorris.net/

 

[Tony Morris]

go read the winzip and pkzip websites where they talk about
proprietary super compressor algorithms.

And do what with that information? Will that somehow invalidate the
java.util.zip package not supporting the zip algorithm?
I think I can wipe my brow - I'm not delusional after all.

--
Tony Morris
http://tmorris.net/

Java Questions and Answers
http://jqa.tmorris.net/

 

[Roedy Green]

Why aren't you using the java.util.zip package?

Java.util.zip has one big drawback. It only understands a few of the
possible compression algorithms. It pretty well can only deal with
zips created by itself. If the zip came from the outside world, you
need to exec something like wzunzip or pkunzip.

 

[Roedy Green]

WTF? Got any proof?

go read the winzip and pkzip websites where they talk about
proprietary super compressor algorithms.

 

[Roedy Green]

And do what with that information? Will that somehow invalidate the
java.util.zip package not supporting the zip algorithm?
I think I can wipe my brow - I'm not delusional after all.

If you go downloading zips out on the net, they could be compressed
with any of a dozen algorithms. If you try to unpack them with Java
you will often fail. If you create zips, few other people will have
trouble with them. See my raspberry on one cheap trick java.util.zip
does, perhaps unavoidably. It screwed me up when I was trying to
process zips produed by Java.. See
http://mindprod.com/jgloss/zip.html

Zip has two uses, as an interchange format where its permissiveness
for alternative algorithms as a pain in the butt, and locally for
squeezing where it allows for innovation and much better performance.

What makes it worse is some compression algorithms are considered
secret and proprietary. PHHT! In heaven Katz would demand all
alternates have public specifications and reference implemenations.

 

[Luc The Perverse]

And do what with that information? Will that somehow invalidate the
java.util.zip package not supporting the zip algorithm?
I think I can wipe my brow - I'm not delusional after all.

I think you need to take some medication and settle down.

Depending on what you are trying to to do with java.util.zip this could be a
serious problem - and people will blame you, not the maker of a proprietary
or non conforming algorithm.