What is the use case for null(Input/Output)Stream API in Java?
With Java 11, I could initialize an InputStream
as:
InputStream inputStream = InputStream.nullInputStream();
But I am unable to understand a potential use case of InputStream.nullInputStream
or a similar API for OutputStream
i.e. OutputStream.nullOutputStream
.
From the API Javadocs, I could figure out that it
Returns a new
InputStream
that reads no bytes. The returned stream is
initially open. The stream is closed by calling the close() method.
Subsequent calls to
close()
have no effect. While the stream is open,
theavailable()
,read()
,read(byte)
, ...
skip(long)
, andtransferTo()
methods all behave as if end of stream
has been reached.
I went through the detailed release notes further which states:
There are various times where I would like to use methods that require
as a parameter a target OutputStream/Writer for sending output, but
would like to execute those methods silently for their other effects.
This corresponds to the ability in Unix to redirect command output to
/dev/null, or in DOS to append command output to NUL.
Yet I fail to understand what are those methods in the statement as stated as .... execute those methods silently for their other effects. (blame my lack of hands-on with the APIs)
Can someone help me understand what is the usefulness of having such an input or output stream with a help of an example if possible?
Edit: One of a similar implementation I could find on browsing further is apache-commons' NullInputStream
, which does justify the testing use case much better.
java inputstream apache-commons outputstream java-11
|
show 1 more comment
With Java 11, I could initialize an InputStream
as:
InputStream inputStream = InputStream.nullInputStream();
But I am unable to understand a potential use case of InputStream.nullInputStream
or a similar API for OutputStream
i.e. OutputStream.nullOutputStream
.
From the API Javadocs, I could figure out that it
Returns a new
InputStream
that reads no bytes. The returned stream is
initially open. The stream is closed by calling the close() method.
Subsequent calls to
close()
have no effect. While the stream is open,
theavailable()
,read()
,read(byte)
, ...
skip(long)
, andtransferTo()
methods all behave as if end of stream
has been reached.
I went through the detailed release notes further which states:
There are various times where I would like to use methods that require
as a parameter a target OutputStream/Writer for sending output, but
would like to execute those methods silently for their other effects.
This corresponds to the ability in Unix to redirect command output to
/dev/null, or in DOS to append command output to NUL.
Yet I fail to understand what are those methods in the statement as stated as .... execute those methods silently for their other effects. (blame my lack of hands-on with the APIs)
Can someone help me understand what is the usefulness of having such an input or output stream with a help of an example if possible?
Edit: One of a similar implementation I could find on browsing further is apache-commons' NullInputStream
, which does justify the testing use case much better.
java inputstream apache-commons outputstream java-11
2
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
3
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do> /dev/null
. Also - testing!
– Boris the Spider
Nov 23 '18 at 15:00
8
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
2
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
1
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23
|
show 1 more comment
With Java 11, I could initialize an InputStream
as:
InputStream inputStream = InputStream.nullInputStream();
But I am unable to understand a potential use case of InputStream.nullInputStream
or a similar API for OutputStream
i.e. OutputStream.nullOutputStream
.
From the API Javadocs, I could figure out that it
Returns a new
InputStream
that reads no bytes. The returned stream is
initially open. The stream is closed by calling the close() method.
Subsequent calls to
close()
have no effect. While the stream is open,
theavailable()
,read()
,read(byte)
, ...
skip(long)
, andtransferTo()
methods all behave as if end of stream
has been reached.
I went through the detailed release notes further which states:
There are various times where I would like to use methods that require
as a parameter a target OutputStream/Writer for sending output, but
would like to execute those methods silently for their other effects.
This corresponds to the ability in Unix to redirect command output to
/dev/null, or in DOS to append command output to NUL.
Yet I fail to understand what are those methods in the statement as stated as .... execute those methods silently for their other effects. (blame my lack of hands-on with the APIs)
Can someone help me understand what is the usefulness of having such an input or output stream with a help of an example if possible?
Edit: One of a similar implementation I could find on browsing further is apache-commons' NullInputStream
, which does justify the testing use case much better.
java inputstream apache-commons outputstream java-11
With Java 11, I could initialize an InputStream
as:
InputStream inputStream = InputStream.nullInputStream();
But I am unable to understand a potential use case of InputStream.nullInputStream
or a similar API for OutputStream
i.e. OutputStream.nullOutputStream
.
From the API Javadocs, I could figure out that it
Returns a new
InputStream
that reads no bytes. The returned stream is
initially open. The stream is closed by calling the close() method.
Subsequent calls to
close()
have no effect. While the stream is open,
theavailable()
,read()
,read(byte)
, ...
skip(long)
, andtransferTo()
methods all behave as if end of stream
has been reached.
I went through the detailed release notes further which states:
There are various times where I would like to use methods that require
as a parameter a target OutputStream/Writer for sending output, but
would like to execute those methods silently for their other effects.
This corresponds to the ability in Unix to redirect command output to
/dev/null, or in DOS to append command output to NUL.
Yet I fail to understand what are those methods in the statement as stated as .... execute those methods silently for their other effects. (blame my lack of hands-on with the APIs)
Can someone help me understand what is the usefulness of having such an input or output stream with a help of an example if possible?
Edit: One of a similar implementation I could find on browsing further is apache-commons' NullInputStream
, which does justify the testing use case much better.
java inputstream apache-commons outputstream java-11
java inputstream apache-commons outputstream java-11
edited Nov 23 '18 at 16:04
nullpointer
asked Nov 23 '18 at 14:52
![](https://i.stack.imgur.com/oxsP9.jpg?s=32&g=1)
![](https://i.stack.imgur.com/oxsP9.jpg?s=32&g=1)
nullpointernullpointer
47.9k11100194
47.9k11100194
2
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
3
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do> /dev/null
. Also - testing!
– Boris the Spider
Nov 23 '18 at 15:00
8
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
2
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
1
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23
|
show 1 more comment
2
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
3
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do> /dev/null
. Also - testing!
– Boris the Spider
Nov 23 '18 at 15:00
8
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
2
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
1
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23
2
2
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
3
3
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do
> /dev/null
. Also - testing!– Boris the Spider
Nov 23 '18 at 15:00
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do
> /dev/null
. Also - testing!– Boris the Spider
Nov 23 '18 at 15:00
8
8
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
2
2
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
1
1
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23
|
show 1 more comment
3 Answers
3
active
oldest
votes
Sometimes you want to have a parameter of InputStream type, but also to be able to choose not to feed your code with any data. In tests it's probably easier to mock it but in production you may choose to bind null input instead of scattering your code with if
s and flags.
compare:
class ComposableReprinter {
void reprint(InputStream is) throws IOException {
System.out.println(is.read());
}
void bla() {
reprint(InputStream.nullInputStream());
}
}
with this:
class ControllableReprinter {
void reprint(InputStream is, boolean for_real) throws IOException {
if (for_real) {
System.out.println(is.read());
}
}
void bla() {
reprint(new BufferedInputStream(), false);
}
}
or this:
class NullableReprinter {
void reprint(InputStream is) throws IOException {
if (is != null) {
System.out.println(is.read());
}
}
void bla() {
reprint(null);
}
}
It makes more sense with output IMHO. Input is probably more for consistency.
This approach is called Null Object: https://en.wikipedia.org/wiki/Null_object_pattern
9
And this is in no way new or Java-specific. Unix has long had/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or usedNUL
device, which is similar (and which came from DOS).
– John Bollinger
Nov 23 '18 at 16:22
add a comment |
I see it as a safer (1) and more expressive (2) alternative to initialising a stream variable with null
.
- No worries about NPEs.
[Output|Input]Stream
is an abstraction. In order to return a null/empty/mock stream, you had to deviate from the core concept down to a specific implementation.
6
This is the answer. This is the same reason/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.
– Boris the Spider
Nov 23 '18 at 15:59
add a comment |
I think nullOutputStream
is very easy and clear: just to discard output (similar to > /dev/null
) and/or for testing (no need to invent an OutputStream
).
An (obviously basic) example:
OutputStream out = ... // an easy way to either print it to System.out or just discard all prints, setting it basically to the nullOutputStream
out.println("yeah... or not");
exporter.exportTo(out); // discard or real export?
Regarding nullInputStream
it's probably more for testing (I don't like mocks) and APIs requiring an input stream or (this now being more probable) delivering an input stream which does not contain any data, or you can't deliver and where null
is not a viable option:
importer.importDocument("name", /* input stream... */);
InputStream inputStream = content.getInputStream(); // better having no data to read, then getting a null
When you test that importer, you can just use a nullInputStream
there, again instead of inventing your own InputStream
or instead of using a mock. Other use cases here rather look like a workaround or misuse of the API ;-)
Regarding the return of an InputStream
: that rather makes sense. If you haven't any data you may want to return that nullInputStream
instead of null
so that callers do not have to deal with null
and can just read as they would if there was data.
Finally, these are just convenience methods to make our lifes easier without adding another dependency ;-) and as others already stated (comments/answers), it's basically an implementation of the null object pattern.
Using the null*Stream
might also have the benefit that tests are executed faster... if you stream real data (of course... depending on size, etc.) you may just slow down your tests unnecessarily and we all want tests to complete fast, right? (some will put in mocks here... well...)
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53448840%2fwhat-is-the-use-case-for-nullinput-outputstream-api-in-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sometimes you want to have a parameter of InputStream type, but also to be able to choose not to feed your code with any data. In tests it's probably easier to mock it but in production you may choose to bind null input instead of scattering your code with if
s and flags.
compare:
class ComposableReprinter {
void reprint(InputStream is) throws IOException {
System.out.println(is.read());
}
void bla() {
reprint(InputStream.nullInputStream());
}
}
with this:
class ControllableReprinter {
void reprint(InputStream is, boolean for_real) throws IOException {
if (for_real) {
System.out.println(is.read());
}
}
void bla() {
reprint(new BufferedInputStream(), false);
}
}
or this:
class NullableReprinter {
void reprint(InputStream is) throws IOException {
if (is != null) {
System.out.println(is.read());
}
}
void bla() {
reprint(null);
}
}
It makes more sense with output IMHO. Input is probably more for consistency.
This approach is called Null Object: https://en.wikipedia.org/wiki/Null_object_pattern
9
And this is in no way new or Java-specific. Unix has long had/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or usedNUL
device, which is similar (and which came from DOS).
– John Bollinger
Nov 23 '18 at 16:22
add a comment |
Sometimes you want to have a parameter of InputStream type, but also to be able to choose not to feed your code with any data. In tests it's probably easier to mock it but in production you may choose to bind null input instead of scattering your code with if
s and flags.
compare:
class ComposableReprinter {
void reprint(InputStream is) throws IOException {
System.out.println(is.read());
}
void bla() {
reprint(InputStream.nullInputStream());
}
}
with this:
class ControllableReprinter {
void reprint(InputStream is, boolean for_real) throws IOException {
if (for_real) {
System.out.println(is.read());
}
}
void bla() {
reprint(new BufferedInputStream(), false);
}
}
or this:
class NullableReprinter {
void reprint(InputStream is) throws IOException {
if (is != null) {
System.out.println(is.read());
}
}
void bla() {
reprint(null);
}
}
It makes more sense with output IMHO. Input is probably more for consistency.
This approach is called Null Object: https://en.wikipedia.org/wiki/Null_object_pattern
9
And this is in no way new or Java-specific. Unix has long had/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or usedNUL
device, which is similar (and which came from DOS).
– John Bollinger
Nov 23 '18 at 16:22
add a comment |
Sometimes you want to have a parameter of InputStream type, but also to be able to choose not to feed your code with any data. In tests it's probably easier to mock it but in production you may choose to bind null input instead of scattering your code with if
s and flags.
compare:
class ComposableReprinter {
void reprint(InputStream is) throws IOException {
System.out.println(is.read());
}
void bla() {
reprint(InputStream.nullInputStream());
}
}
with this:
class ControllableReprinter {
void reprint(InputStream is, boolean for_real) throws IOException {
if (for_real) {
System.out.println(is.read());
}
}
void bla() {
reprint(new BufferedInputStream(), false);
}
}
or this:
class NullableReprinter {
void reprint(InputStream is) throws IOException {
if (is != null) {
System.out.println(is.read());
}
}
void bla() {
reprint(null);
}
}
It makes more sense with output IMHO. Input is probably more for consistency.
This approach is called Null Object: https://en.wikipedia.org/wiki/Null_object_pattern
Sometimes you want to have a parameter of InputStream type, but also to be able to choose not to feed your code with any data. In tests it's probably easier to mock it but in production you may choose to bind null input instead of scattering your code with if
s and flags.
compare:
class ComposableReprinter {
void reprint(InputStream is) throws IOException {
System.out.println(is.read());
}
void bla() {
reprint(InputStream.nullInputStream());
}
}
with this:
class ControllableReprinter {
void reprint(InputStream is, boolean for_real) throws IOException {
if (for_real) {
System.out.println(is.read());
}
}
void bla() {
reprint(new BufferedInputStream(), false);
}
}
or this:
class NullableReprinter {
void reprint(InputStream is) throws IOException {
if (is != null) {
System.out.println(is.read());
}
}
void bla() {
reprint(null);
}
}
It makes more sense with output IMHO. Input is probably more for consistency.
This approach is called Null Object: https://en.wikipedia.org/wiki/Null_object_pattern
edited Nov 23 '18 at 15:58
answered Nov 23 '18 at 15:06
Milo BemMilo Bem
822418
822418
9
And this is in no way new or Java-specific. Unix has long had/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or usedNUL
device, which is similar (and which came from DOS).
– John Bollinger
Nov 23 '18 at 16:22
add a comment |
9
And this is in no way new or Java-specific. Unix has long had/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or usedNUL
device, which is similar (and which came from DOS).
– John Bollinger
Nov 23 '18 at 16:22
9
9
And this is in no way new or Java-specific. Unix has long had
/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or used NUL
device, which is similar (and which came from DOS).– John Bollinger
Nov 23 '18 at 16:22
And this is in no way new or Java-specific. Unix has long had
/dev/null
, for example, which serves much the same purpose at a different level. Windows has the little-known or used NUL
device, which is similar (and which came from DOS).– John Bollinger
Nov 23 '18 at 16:22
add a comment |
I see it as a safer (1) and more expressive (2) alternative to initialising a stream variable with null
.
- No worries about NPEs.
[Output|Input]Stream
is an abstraction. In order to return a null/empty/mock stream, you had to deviate from the core concept down to a specific implementation.
6
This is the answer. This is the same reason/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.
– Boris the Spider
Nov 23 '18 at 15:59
add a comment |
I see it as a safer (1) and more expressive (2) alternative to initialising a stream variable with null
.
- No worries about NPEs.
[Output|Input]Stream
is an abstraction. In order to return a null/empty/mock stream, you had to deviate from the core concept down to a specific implementation.
6
This is the answer. This is the same reason/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.
– Boris the Spider
Nov 23 '18 at 15:59
add a comment |
I see it as a safer (1) and more expressive (2) alternative to initialising a stream variable with null
.
- No worries about NPEs.
[Output|Input]Stream
is an abstraction. In order to return a null/empty/mock stream, you had to deviate from the core concept down to a specific implementation.
I see it as a safer (1) and more expressive (2) alternative to initialising a stream variable with null
.
- No worries about NPEs.
[Output|Input]Stream
is an abstraction. In order to return a null/empty/mock stream, you had to deviate from the core concept down to a specific implementation.
edited Nov 23 '18 at 15:23
answered Nov 23 '18 at 15:14
Andrew TobilkoAndrew Tobilko
27.3k104285
27.3k104285
6
This is the answer. This is the same reason/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.
– Boris the Spider
Nov 23 '18 at 15:59
add a comment |
6
This is the answer. This is the same reason/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.
– Boris the Spider
Nov 23 '18 at 15:59
6
6
This is the answer. This is the same reason
/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.– Boris the Spider
Nov 23 '18 at 15:59
This is the answer. This is the same reason
/dev/null
exists on UNIX systems - because otherwise the "null" output would need to be treated differently.– Boris the Spider
Nov 23 '18 at 15:59
add a comment |
I think nullOutputStream
is very easy and clear: just to discard output (similar to > /dev/null
) and/or for testing (no need to invent an OutputStream
).
An (obviously basic) example:
OutputStream out = ... // an easy way to either print it to System.out or just discard all prints, setting it basically to the nullOutputStream
out.println("yeah... or not");
exporter.exportTo(out); // discard or real export?
Regarding nullInputStream
it's probably more for testing (I don't like mocks) and APIs requiring an input stream or (this now being more probable) delivering an input stream which does not contain any data, or you can't deliver and where null
is not a viable option:
importer.importDocument("name", /* input stream... */);
InputStream inputStream = content.getInputStream(); // better having no data to read, then getting a null
When you test that importer, you can just use a nullInputStream
there, again instead of inventing your own InputStream
or instead of using a mock. Other use cases here rather look like a workaround or misuse of the API ;-)
Regarding the return of an InputStream
: that rather makes sense. If you haven't any data you may want to return that nullInputStream
instead of null
so that callers do not have to deal with null
and can just read as they would if there was data.
Finally, these are just convenience methods to make our lifes easier without adding another dependency ;-) and as others already stated (comments/answers), it's basically an implementation of the null object pattern.
Using the null*Stream
might also have the benefit that tests are executed faster... if you stream real data (of course... depending on size, etc.) you may just slow down your tests unnecessarily and we all want tests to complete fast, right? (some will put in mocks here... well...)
add a comment |
I think nullOutputStream
is very easy and clear: just to discard output (similar to > /dev/null
) and/or for testing (no need to invent an OutputStream
).
An (obviously basic) example:
OutputStream out = ... // an easy way to either print it to System.out or just discard all prints, setting it basically to the nullOutputStream
out.println("yeah... or not");
exporter.exportTo(out); // discard or real export?
Regarding nullInputStream
it's probably more for testing (I don't like mocks) and APIs requiring an input stream or (this now being more probable) delivering an input stream which does not contain any data, or you can't deliver and where null
is not a viable option:
importer.importDocument("name", /* input stream... */);
InputStream inputStream = content.getInputStream(); // better having no data to read, then getting a null
When you test that importer, you can just use a nullInputStream
there, again instead of inventing your own InputStream
or instead of using a mock. Other use cases here rather look like a workaround or misuse of the API ;-)
Regarding the return of an InputStream
: that rather makes sense. If you haven't any data you may want to return that nullInputStream
instead of null
so that callers do not have to deal with null
and can just read as they would if there was data.
Finally, these are just convenience methods to make our lifes easier without adding another dependency ;-) and as others already stated (comments/answers), it's basically an implementation of the null object pattern.
Using the null*Stream
might also have the benefit that tests are executed faster... if you stream real data (of course... depending on size, etc.) you may just slow down your tests unnecessarily and we all want tests to complete fast, right? (some will put in mocks here... well...)
add a comment |
I think nullOutputStream
is very easy and clear: just to discard output (similar to > /dev/null
) and/or for testing (no need to invent an OutputStream
).
An (obviously basic) example:
OutputStream out = ... // an easy way to either print it to System.out or just discard all prints, setting it basically to the nullOutputStream
out.println("yeah... or not");
exporter.exportTo(out); // discard or real export?
Regarding nullInputStream
it's probably more for testing (I don't like mocks) and APIs requiring an input stream or (this now being more probable) delivering an input stream which does not contain any data, or you can't deliver and where null
is not a viable option:
importer.importDocument("name", /* input stream... */);
InputStream inputStream = content.getInputStream(); // better having no data to read, then getting a null
When you test that importer, you can just use a nullInputStream
there, again instead of inventing your own InputStream
or instead of using a mock. Other use cases here rather look like a workaround or misuse of the API ;-)
Regarding the return of an InputStream
: that rather makes sense. If you haven't any data you may want to return that nullInputStream
instead of null
so that callers do not have to deal with null
and can just read as they would if there was data.
Finally, these are just convenience methods to make our lifes easier without adding another dependency ;-) and as others already stated (comments/answers), it's basically an implementation of the null object pattern.
Using the null*Stream
might also have the benefit that tests are executed faster... if you stream real data (of course... depending on size, etc.) you may just slow down your tests unnecessarily and we all want tests to complete fast, right? (some will put in mocks here... well...)
I think nullOutputStream
is very easy and clear: just to discard output (similar to > /dev/null
) and/or for testing (no need to invent an OutputStream
).
An (obviously basic) example:
OutputStream out = ... // an easy way to either print it to System.out or just discard all prints, setting it basically to the nullOutputStream
out.println("yeah... or not");
exporter.exportTo(out); // discard or real export?
Regarding nullInputStream
it's probably more for testing (I don't like mocks) and APIs requiring an input stream or (this now being more probable) delivering an input stream which does not contain any data, or you can't deliver and where null
is not a viable option:
importer.importDocument("name", /* input stream... */);
InputStream inputStream = content.getInputStream(); // better having no data to read, then getting a null
When you test that importer, you can just use a nullInputStream
there, again instead of inventing your own InputStream
or instead of using a mock. Other use cases here rather look like a workaround or misuse of the API ;-)
Regarding the return of an InputStream
: that rather makes sense. If you haven't any data you may want to return that nullInputStream
instead of null
so that callers do not have to deal with null
and can just read as they would if there was data.
Finally, these are just convenience methods to make our lifes easier without adding another dependency ;-) and as others already stated (comments/answers), it's basically an implementation of the null object pattern.
Using the null*Stream
might also have the benefit that tests are executed faster... if you stream real data (of course... depending on size, etc.) you may just slow down your tests unnecessarily and we all want tests to complete fast, right? (some will put in mocks here... well...)
edited Nov 23 '18 at 16:25
answered Nov 23 '18 at 15:45
RolandRoland
10k11241
10k11241
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53448840%2fwhat-is-the-use-case-for-nullinput-outputstream-api-in-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
While asking the question, at some point in time I got this question as a suggestion to look at. Neither the links there land to proper sites and nor do I have an experience of working with the JDK where the line of code could be found. Maybe I am missing something, hence linking it here.
– nullpointer
Nov 23 '18 at 14:55
3
How would you pass a stream to file that doesn't exist to a method where this is optional for example. How would you tell a method to discard data - i.e. how do you do
> /dev/null
. Also - testing!– Boris the Spider
Nov 23 '18 at 15:00
8
It's an implementation of the null object pattern. If you get what the pattern is about you'll get what's the use of null streams.
– plalx
Nov 23 '18 at 15:08
2
@BoristheSpider I do somewhat understand theoretically what it means in terms of while willing to discard the data from a stream, but why should one be doing it(discarding data)? Could there be any services/systems I should be aware to know such an implementation? Testing - yes, does make sense to contribute to that as well.
– nullpointer
Nov 23 '18 at 15:21
1
@plalx Thanks for the link.I could correlate it to the discussion in the detailed release note over compatibility issues while making changes to create a null safe implementation for i/o streams. Would read about it further and digest it more wisely. Thanks again.
– nullpointer
Nov 23 '18 at 15:23