Lion-O said:
But doesn't it also implying that the person in question needs to know
certain libraries and their inner workings from mind ? I somewhat cannot
fully place that, since Java is so extensive (from my point of view at
least) that I find it rather hard to be able and grasp the meaning /
inner workings of certain classes / methods without the Javadoc API specs.
That's a reasonable attitude, but I think that Adam's questions are a bit more
subtle than you might think. I'll try to give answers to them (not the best
possible answers, just acceptable ones), to say why those answers must be true,
why I would expect almost any Java programmer to be able to answer them
correctly, and why I think they do probe some aspects of real understanding.
BTW, if you aren't yet able to answer these yourself, please don't take it
personally ;-) You've said that you're a beginner here, and everyone has to
start somewhere.
It's easier to take the questions out of order.
Q What does Object.hashCode() do?
A Gives you an integer that can be used to locate objects in hashed collections
like HashSet or HashMap.
Since HashSet and HashMap are important utility classes, I would expect anyone
to have at least some experience with them. More on this below.
Q What does String.hashCode() do?
A It gives you a number to use as a hash code which depends only on the
characters in the String.
It may seem surprising that this is something I regard as basic understanding,
So basic that I would /require/ someone to know it or be able to work out the
answer. The logic is as follows:
Strings are absolutely central to Java programming.
There are some basic facts about Strings that everyone
/has/ to know.
One of those facts is that you shouldn't compare Strings
using ==. You must (nearly always) use the equals()
method, which overrides the Object.equals() method to
compare the two strings character-by-character.
Therefore (see below) Strings must also provide their
own override of hashCode() too, which is compatible with equals(). (To use
the technical term; you are not requred to know the jargon ;-)
To be compatible with equals() requires that the hashCode()
only depend on the characters in the String.
Therefore that's what String.hashCode() does.
(A more knowledgeable programmer might know more, but anyone should be able to
answer that much -- at least if they weren't too nervous to think.)
Q Can you override String.hashCode()?
A No.
If the answer was because String.hashCode() was declared final then it's not
something I would regard as particularly indicative -- it would just be one of
those facts that you either know or don't know. But the actual reason is that
the String class /itself/ is final, and /that/ is one of the basic facts about
Strings that I think everyone should know (another such fact is that Strings
are immutable).
Q What does System.identiyHashCode() do?
A It tells you a hash code for an object that only depends on /which/ object
it is. So that it is compatible with ==, in the same way as hashCode() is
expected to be compatible with equals().
To be honest, I wouldn't call this question as relevant as the others. I can
easily imagine someone being moderately competent and never having come across
the need for hashing based on identity. OTOH, even a moderate curiosity about
the java.util package would lead a programmer to discover these things -- and
java.util is one of the packages that I would expect /any/ Java programmer to
be curious about.
One assumption that I've made in the above is that you are expected to know
about the relationship between hashCode() and equals(). The reason for that is
simply that I would expect any programmer to have used the hashed collections,
I would expect any programmer to have had some experience of creating their own
classes, and I would consider it extraordinary if that programmer had never had
to put instances of his or her classes into a collection nor ever had to
compare them for equality. These are basic skills. And in order to do these
things, you need to understand equals() and hashCode() and the relationship
between them.
Obviously those questions don't cover all the basics. There are probably other
(equally small) sets of questions that would probe a selection of basics that
I'd prefer. But -- as I've said -- my experience is that people tend either to
have the kinds of minds, experience, and training, that emphasise
/understanding/ and therefore naturally cover all the basics, or they have
missed out badly somewhere. And in the latter case, I would not care to employ
them.
-- chris
