The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Oct 20, 2005
I feel there won't be any use case for adding NULL as a key and store a value for it. I wonder why such a feature is allowed by java and some real world examples will help me to understand the use of this feature.
Could be used to supply a default value I suppose. I'm imagining a situation where an application gives you a choice of options, and the result of these options are mapped with a HashMap. Now suppose this option choice is itself optional. The user hasn't selected anything therefore the choice is null, so return whatever value is in the Map with a null key.
Might not be how this is used, but I can't think of any benefit of preventing people using a null key?
One real life scenario where even a "null" can convey information.
I am working on a project where I have "jobs" (e.g. copy some data from some place to another). I also have a "schedule" which can be associated to the "jobs". The "schedule" contains information on at what time the job should be executed and when should it be repeated. There is a simple check which we have put in. If the job schedule is null, we execute the job only once. Else we execute it as per schedule.
Several people have given useful examples of when a null key is useful, but the real answer to the original question is that whoever designed the class thought it would be most useful like that.
Joined: Jul 11, 2001
Originally posted by CM Ananth: I feel there won't be any use case for adding NULL as a key and store a value for it. I wonder why such a feature is allowed by java and some real world examples will help me to understand the use of this feature.
I think the question should be reverted: how would disallowing null as a key be useful?
Why actively disallow something just because we can't yet think of a case where it would be useful?
Implementing your own version of HashMap that doesn't allow a null is easy by just extending or wrapping the HashMap class and putting some extra checking in. Whereas creating your own class that allowed nulls if HashMap didn't allow them would be a little more difficult.
Hello - i was running some basic code tests to try and do this and keep getting a runtime exception whenever i add another element to the Map/Set after putting a null key initially. Seems that it always fails on the equals method when comparing the current object being inserted to the previous null entry. This makes sense so i am curious how this is implemented in the real world. A bit confused.
Any thoughts? Thanks.
Joined: Aug 05, 2005
Brian Carlisle wrote:Hello - i was running some basic code tests to try and do this and keep getting a runtime exception whenever i add another element to the Map/Set after putting a null key initially. Seems that it always fails on the equals method when comparing the current object being inserted to the previous null entry. This makes sense so i am curious how this is implemented in the real world. A bit confused..
Can you show us the code you are using and what exception you are getting. It works fine for me.
Specifically, look at the equals() method of the class you are putting in to the map. I would suspect that is where the exception is coming from.
Joined: Oct 30, 2012
Sure - taken from the SCJP book. I added the null entry to see what would happen. Also tried changing the int to String for size and using equals() but no luck. The same happens when i convert the code to use a LinkedHashMap.
It makes sense to me logically why the exception is thrown.
Joined: Oct 30, 2012
Yes it is most certainly in the equals method. Can you show me a simple example of this working? Much appreciated.
This equals() method isn't very good. The error is on line 3 (in the if condition). You assume the Object being compared to (o) is not null, you dereference it without first checking if it was nulll. So this would fail. You need to do a first check. A typical equals() method would be like this:
<edit>Forgot the case where other might be of a different type. This is one way of checking that. Another is to use instanceof, but there is a difference in semantics between the two options... I chose to check classes for equality</edit>
I usually follow that flow but shorten it a bit:
I also wonder why in hashCode you divide the size by 5. Why not simply return size itself? It's an int, so it's a valid value.
Edit: I just saw that Steve's example uses Turtle.class to compare to. I prefer not to use one fixed class except if the class is final (in which case I use instanceof). Using getClass() instead allows sub classes to still have a valid equals method. Let's say you have class SnappingTurtle extends Turtle, then in Steve's example a new SnappingTurtle(5) will be equal to a new Turtle(5), which I disagree with. In my example, the two will be unequal even though they have the same size.