Re: Java questions: Urgent
>> 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.
Great, thanks a lot for the effort.
> 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.
Which is the main reason I "butted" in a bit.. A lot of questions like these
which adress "more advanced yet basic" issues can be very valuable information
/ pointers for beginners. IMO ofcourse... I already jotted down a few topics
which others deemed "basic knowledge for Java programmers" in order to read up
on them at a later time. Rest assured that I looked these up myself as well
before responding to it. So no worries, no offense what so ever. I welcome all
the input I can get.
> 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.
Well, this is one of those topics I mentioned earlier which ended up on my todo
to have a closer look see at a later time.
> 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.
Hmm, I'm pleased I got that part close enough. Even though I have to admit not
to have worked with hashes yet, so I don't know much right now on their
specific uses.
> 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:
---<Cut: String.equals() vs. ==
> 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.
Well, I have to admit not having looked at it from this perspective, it makes
good sense to me though. I think I follow your logic here quite well, it does
clearly lay it out as to why you could *reason* to come to the right answer.
Very interesting indeed, I really appreciate the input here.
> (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.
> 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).
Yes, I can relate and agree to this one. Its also something the tutorials
almost start with (if not soon after the basic history). I think, but not sure
from mind, that one of the tutorials I followed even used the String class to
demonstrate the final state.
> Q What does System.identiyHashCode() do?
System.identifyHashCode()
> 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.
That too is something I can relate to. Its why one of the first things I
started with was looking, skimming, reading and trying out the things I found
in the Javadoc API references. Since most of the tutorials quickly tell you
that java.lang and java.util are always loaded it becomes quite clear that
having a little familiarity with them might be very usefull ;) It is also one
of those fields I still lack experience though.
I'm not going into your comments regarding the the need to understand equals()
and hashCode() and their relationship simply because I don't have that kind of
experience yet and I feel it would be ridiculous for me to comment. Still, I do
see and understand your reasoning a lot better now and have to agree on the
part that you should be able to find certain answers through reasoning.
> 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.
*nod*. Thanks again for your very diverse reply on this.
--
Groetjes, Peter
..\\ PGP/GPG key: http://www.catslair.org/pubkey.asc
.
