> 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();

Signature
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Oliver Wong - 27 Jan 2006 20:55 GMT
>> 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
[quoted text clipped - 18 lines]
> }
> }).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
Mike Schilling - 27 Jan 2006 22:02 GMT
>> 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
[quoted text clipped - 18 lines]
> }
> }).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.
> 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
[quoted text clipped - 35 lines]
> 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.
> 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/
Roedy Green - 28 Jan 2006 09:21 GMT
>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.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Tony Morris - 27 Jan 2006 23:35 GMT
> >Why aren't you using the java.util.zip package?
>
[quoted text clipped - 5 lines]
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.
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/
Roedy Green - 28 Jan 2006 10:10 GMT
>WTF? Got any proof?
go read the winzip and pkzip websites where they talk about
proprietary super compressor algorithms.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Tony Morris - 28 Jan 2006 00:31 GMT
> >WTF? Got any proof?
> go read the winzip and pkzip websites where they talk about
> proprietary super compressor algorithms.
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.
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 - 28 Jan 2006 11:34 GMT
>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.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Luc The Perverse - 28 Jan 2006 18:30 GMT
>> >WTF? Got any proof?
>> go read the winzip and pkzip websites where they talk about
[quoted text clipped - 6 lines]
> 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.
--
LTP
:)