[NTLUG:Discuss] Java/Linux versus school teacher.
Chris Cox
cjcox at acm.org
Mon Mar 19 10:54:16 CDT 2007
steve wrote:
> Do we have any Java/Linux guru's in the house?
>
> My son is learning Java in high school - inevitably they use
> Windows machines - but it's Java - which is portable - so it
> doesn't matter a whole lot. So my kid can use Linux to do
> his homework without problems.
>
> ...mostly...
>
> The other day, they had a Java Exam. The first two questions
> go like this:
>
> Assume x and y are String variables with x="Hello" and y=null.
>
> 1) The result of (x==y) is
> a) true
> b) false
> c) a syntax error
> d) a run-time error
> e) x being set to the value null.
>
> I think we can all agree that the answer is (b)false.
>
> 2) It the operation y="Hello"; is performed then the result
> of (x==y) is:
> a) true
> b) false
> c) x and y becoming aliases
> d) x being set to the value null
> e) a run-time error
>
> Question 2 is a problem. My son said "(a) true" but the
> teacher says that the answer is "(b)false" - and whilst
> I'm not a Java expert (I'm a C++ person) I can see why. Even
> though both x and y are set to "Hello", they don't refer to
> the same String object and the '==' operator doesn't compare
> the contents of the objects - it only tests whether the same
> object is being referenced on both sides. (At least according
> to "Java2 for Dummies" and my C++ intuition).
>
> When my son makes mistakes like that, I encourage him to write
> a little program to convince himself. The trouble is that when
> we tested it by writing a little Java program and running it
> under Linux:
>
> String x="Hello";
> String y="Hello";
> if ( x==y )
> println ( "true" ) ;
> else
> println ( "false" ) ;
>
> The answer comes out "true"...oh-oh!
>
> This suggests that some kind of optimisation is going on inside
> the Java compiler and the two instances of the "Hello" string are
> being combined into one single object or something.
>
> Clearly then the teacher is wrong and the correct answer is "either
> true or false depending on the implementation"...but I'm having
> a hard time believing that Java is that ill-specified. Is it in
> fact the case that Java under Windows would also have reported
> 'true'?
>
> So should I complain to the teacher? Stop using Linux for this
> stuff? (over my cold, dead body!)...Or is there something subtle
> that I'm missing here?
>
Unfortunately, teachers are often times "teachers" and not
true treachers :)
In other words, these "teachers" do not realize the plethora
of variables in play that have to be defined explicitly
in order to correctly determine the answer to a problem.
Sad but true.
However, with that said, I don't think there's anything in
Java that says two strings CAN'T equate using "==" to being
true... but you just have to understand they can be DIFFERENT
objects and therefore, you shouldn't ASSUME that using "=="
would produce a true value. It's the teacher's assumption
that "==" means a string content comparison... this is
the information MISSING from the question.
It can be confusing... the teacher was obviously ASSUMING
that the test was for equality of the CONTENT of the
strings and using "==" doesn't test for that (regardless
of whether it returns true or false).
The question could have been more clearly worded.
Or the teacher could have said choose the BEST answer
and given an answer that better fits what is happening
without all of the subjective assumptions.
2) If the operation y="Hello"; is performed then the result
of (x==y) is:
Change to:
Choose the best answer
2) If the operation y="Hello"; is performed and we are
wanting to test that the strings have the same content,
then the result of (x==y) is:
And the answer would have to be:
f) Improper comparison. You cannot use the built-in "=="
comparison operator to compare String content.
Of course, in OO languages that support operator overloading,
the question becomes even more complex (be glad it was java
and not C++ or C#).
Oh.. btw.. I'm NOT a java guru. But I think I understand
enough to respond.
More information about the Discuss
mailing list