• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

closing connections to Process streams

 
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The API docs do not make clear who is responsible for closing what resources when reading the standard output of a Process instance. The docs do recommend buffering, though. So, I would obtain a reader like this: I was concerned that closing the BufferedReader would close the InputStreamReader would close the InputStream of the process. However, the docs for BufferedReader.close() and InputStreamReader.close() don't state whether any underlying Readers/InputStreams will be closed. Is it sufficient, then, to close only the BufferedReader, or should I also close the InputStreamReader? I suppose that the Process is responsible for closing its own streams.

Thanks,
Craig
 
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Craig,

There is only one InputStream here, with two Readers wrapped round it. The close() method on either Reader closes the underlying InputStream (in this case the Process's stdout stream).

You don't want or need to close the Process's stdout, so I would recommend that you don't call close on either Reader. I think it's reasonable to assume that a Process creates its streams when instantiated, rather than when the getXxxStream() method is called, so it should dispose of them when it's finalized.

Jules
 
Craig Demyanovich
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jules,

What is the source of your claim that BufferedReader.close() and/or InputStreamReader.close() closes any underlying streams? I haven't been able to find anything in the API docs that confirm this behavior. I've always thought that Reader.close() worked that way, but I can't remember from where I may have learned this.

Thanks,
Craig
 
JulianInactive KennedyInactive
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, they both extend Reader and override its close() method, right? What does Reader's close method close? There's only one thing that makes any sense to me and that's the InputStream. Anyway, it's not too hard to test - try it. My source is O'Reilly's Java in a Nutshell ... and process of elimination, I guess.

Jules
 
Ranch Hand
Posts: 115
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
if youre really not happy - dont use anonymous references to the other streams and close them only when you want to:

eg:

Which seems pretty lame to me^^

If youre concerened that the InputStream will close when you dont want it to you can always call it again from the process reference.
 
JulianInactive KennedyInactive
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To exorcise any remaining doubts (hopefully):

Jules
 
Craig Demyanovich
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jules,

Thanks for reminding us to always verify with code, like your sample application or a unit test. Rather than close the readers, which closes the stream of the process, I'll let the process take responsibility for its own streams.

While doing further research on this topic earlier, I found this JavaWorld article, When Runtime.exec() won't.

Craig
 
This is awkward. I've grown a second evil head. I'm going to need a machete and a tiny ad ...
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic