Comparing to null

Thread view:

Steve Brecher - 23 Nov 2006 22:00 GMT

String s = (new BufferedReader(new
InputStreamReader(System.in))).readLine();

myOutputFile.println("s: " + s + "; (s == null): " + (s == null));

Output:
s: null; (s == null): false

My question is how the output is possible.

Signature

For mail, please use my surname where indicated:
steve@surname.reno.nv.us (Steve Brecher)

Reply to this Message

Steve Brecher - 23 Nov 2006 22:24 GMT

> String s = (new BufferedReader(new
> InputStreamReader(System.in))).readLine();
[quoted text clipped - 5 lines]
>
> My question is how the output is possible.

It's possible if s contains the four letters n, u, l, ,l, which is the case.
How THAT is possible may be the subject of another thread.

Signature

For mail, please use my surname where indicated:
steve@surname.reno.nv.us (Steve Brecher)

Reply to this Message

Andreas Wollschlaeger - 23 Nov 2006 22:34 GMT

> String s = (new BufferedReader(new
> InputStreamReader(System.in))).readLine();
[quoted text clipped - 5 lines]
>
> My question is how the output is possible.

What JVM was this? Just tried this from within Netbeans by closing the
input stream when prompted and get the expected result:

s: null; (s == null): true

Or did you feed "null" (verbatim) as input string?

Yields: s: null; (s == null): false ;-)

Greetings
Andreas

Reply to this Message

Karl Uppiano - 23 Nov 2006 23:23 GMT

>> String s = (new BufferedReader(new
>> InputStreamReader(System.in))).readLine();
[quoted text clipped - 12 lines]
>
> Or did you feed "null" (verbatim) as input string?

That was my guess. The stream reader read in the string "null".

My other guess is that this is a trick homework question that the professor
posed to his/her students.

Reply to this Message

Steve Brecher - 24 Nov 2006 01:29 GMT

>>> String s = (new BufferedReader(new
>>> InputStreamReader(System.in))).readLine();
[quoted text clipped - 9 lines]
>
> That was my guess. The stream reader read in the string "null".

That was not the case. What I was doing was testing redirecting console
input to be from a text file, using:
java [...] < simultated.console.input.txt
with WinXP.

> My other guess is that this is a trick homework question that the
> professor posed to his/her students.

Heh. Would have been a good one! But my problem turned out to be that I
was doing the
String s = (new BufferedReader( new ...))).readline();
to input each line of input. That works OK for a non-redirected System.in,
but with the redirection it fails for the second line of the input file.
Creating the BufferedReader just once solves the problem.

I still don't know where the literal 4-character string "null" came from --
it wasn't from the input file! And there's no such string literal in my
source code. I'm too experienced (with software, not Java) to swear that I
didn't cause the "null", but its source is still a mystery. However, having
solved my real problem (redirecting console input), I'm moving on.

Signature

For mail, please use my surname where indicated:
steve@surname.reno.nv.us (Steve Brecher)

Reply to this Message

Steve Brecher - 24 Nov 2006 02:29 GMT

> I still don't know where the literal 4-character string "null" came
> from -- it wasn't from the input file! And there's no such string
> literal in my source code. I'm too experienced (with software, not
> Java) to swear that I didn't cause the "null", but its source is
> still a mystery. ...

BufferedReader's readLine returns the 4-character string literal "null" on
end-of-file! The Javadoc says:

Returns:
A String containing the contents of the line, not including any
line-termination characters, or null if the end of the stream has been
reached.

I assumed "null" designates the non-Object reference, not a string literal.
And it's hard for me to understand how it could be implemented to return a
string literal.

Sun jre 1.5.0._09, WinXP.

Signature

For mail, please use my surname where indicated:
steve@surname.reno.nv.us (Steve Brecher)

Reply to this Message

Stefan Ram - 24 Nov 2006 03:01 GMT

>BufferedReader's readLine returns the 4-character string
>literal "null" on end-of-file!

It might return a string, but never a »string literal«,
because a »string literal« is a source-code symbol, not a
run-time value.

Reply to this Message

Steve Brecher - 24 Nov 2006 05:48 GMT

>> BufferedReader's readLine returns the 4-character string
>> literal "null" on end-of-file!
>
> It might return a string, but never a »string literal«,
> because a »string literal« is a source-code symbol, not a
> run-time value.

Yes, my terminology was wrong.

The file in question is the source of redirected console input in WinXP.
The only hypothesis I've come up with since the original post quoted above
is that WinXP is passing the string "null" on end of file. Then it would be
coincidence that the string it passes matches the Java keyword. But it's
not a compelling hypothesis!

Signature

For mail, please use my surname where indicated:
steve@surname.reno.nv.us (Steve Brecher)

Reply to this Message

Simon Brooke - 24 Nov 2006 19:22 GMT

> String s = (new BufferedReader(new
> InputStreamReader(System.in))).readLine();
[quoted text clipped - 5 lines]
>
> My question is how the output is possible.

Ooooh, I know that one. I've suffered from that one - long ago, but it took
a long time to work it out.

It happens when the line you read is composed of the
characters 'n', 'u', 'l', 'l'. And it's /hell/ to debug if you weren't
expecting to get that character sequence on your input stream.

Signature

simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

[ This .sig subject to change without notice ]

Reply to this Message

Comparing to null

Free Magazines