Java has a notion of separate InputStreams and OutputStreams. Your code reads from an InputStream and writes to an OutputStream.

.NET does not have this distinction, instead it has a single Stream class which your code can both write to and read from, depending on the exact implementation. Capabilities can be determined by the CanRead and CanWrite properties.

I'm wondering if there's a fundamental benefit to one approach over the other? All I can come up with is:

  • Code is potentially slightly more concise with a single Stream if you're both reading and writing
  • The close method could be particularly confusing or even dangerous if using separate input and output stream classes which are working with the same underlying stream
  • Separate input and output stream classes make the intention of the code clearer

None of these reasons seems particularly compelling to me. Are there any more compelling reasons I'm missing?

  • 1
    Streams in .NET are used with some underlying data store such as memory or a file, which are inherently read/write/seekable by design. Apparently the .NET designers decided this was a good way to think of a stream. There are, of course, subclasses of TextReader, TextWriter, BinaryReader and BinaryWriter that take a stream as a constructor parameter and, because Stream is a universal reader/writer, it works with all of these, using any compatible data store. – Robert Harvey Aug 8 '19 at 20:41
  • @RobertHarvey I get a hint that you think the .NET implementation is inferior. Is that true? If so, why? – Ian Newson Aug 8 '19 at 20:47
  • 1
    The .NET implementation is fine. At the end of the day, there really isn't all that much difference in the two implementations, other than flavor. InputStream and OutputStream are abstract classes; .NET just combined them into a single abstract class, that's all. And because they're abstract classes in both frameworks, end users will barely notice the difference, because the abstract class will always be wrapped in a reader/writer implementation. – Robert Harvey Aug 8 '19 at 20:48
  • 2
    If anything, the .NET implementation is a bit more flexible, because you can create a Reader/Writer with it. – Robert Harvey Aug 8 '19 at 20:51
  • You would save number of open file descriptors with using a Single stream. Keeping separate input and output streams would consume two file descriptors. – Xolve Aug 16 '19 at 18:17

You can only say one is better than the other in particular circumstances. 9 times out of 10, there isn't an important enough difference to really care which direction the stream is intended to be used.

In some cases, the underlying stream is truly bidirectional (I'm looking at you Sockets, Files). In Java you have to get two different stream objects to have the conversation, while in .NET you only need to deal with one. Under the covers, the Java Socket Input Stream simply used the same operating system object as the Output Stream.

Those are all implementation details. As RobertHarvey pointed out in his comment, .Net does indeed have unidirectional adapters for the underlying stream.

If you've ever wanted to reverse a pipeline, the flexibility of the .Net implementation is really handy.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.