We Keep Coding

Map.ofEntries gives Null Pointer Exception on checking NULL key using containsKey()

I was fetching key from a constant map earlier using HashMap.
On passing a NULL key at containsKey(), I used to get FALSE.
To make the code look fancy, I tried java-8 over it. So, instead of HashMap, I started using Map.ofEntries to build my map
Surprisingly, I got Null Pointer Exception when a Null key was passed to containsKey() method
String str = null;
Map<String,String> hashMap = new HashMap<>();
hashMap.put("k1", "v1");
System.out.print(hashMap.containsKey(str)); // This gives false
Map<String,String> ofEntriesMap = Map.ofEntries( Map.entry("k1", "v1"));
System.out.print(ofEntriesMap.containsKey(str)); // Why this gives Null Pointer Exception ?
I am unable to figure out, why it is behaving differently at Map.ofEntries.
What is the best way to handle this situation ?

The javadoc of Map says:
Unmodifiable Maps
The Map.of, Map.ofEntries, and Map.copyOf static factory methods provide a convenient way to create unmodifiable maps. The Map instances created by these methods have the following characteristics:
They are unmodifiable. Keys and values cannot be added, removed, or updated. Calling any mutator method on the Map will always cause UnsupportedOperationException to be thrown. However, if the contained keys or values are themselves mutable, this may cause the Map to behave inconsistently or its contents to appear to change.
They disallow null keys and values. Attempts to create them with null keys or values result in NullPointerException.
...
In contrast, the javadoc of HashMap says:
Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls.) This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.
...

instead of HashMap, I started using Map.ofEntries to build my map
Surprisingly, I got Null Pointer Exception when a Null key was passed
to containsKey() method
The documentation for java.util.Map says, in part:
Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null
keys and values, and some have restrictions on the types of their
keys. Attempting to insert an ineligible key or value throws an
unchecked exception, typically NullPointerException or
ClassCastException. Attempting to query the presence of an
ineligible key or value may throw an exception, or it may simply
return false; some implementations will exhibit the former behavior
and some will exhibit the latter.
(Emphasis added.)
As #Andreas's answer already observes, the maps created via Map.ofEntries() are of such an implementation. Specifically, they disallow null keys and values. Although it is not documented whether their containsKey() methods exercise the option to throw when presented with a null argument, you need to use them with that possibility in mind.
On the other hand, as Andreas also shows, HashMap is documented to permit null keys and values, so its containsKey() method is expected to complete normally when passed a null argument.
What is the best way to handle this situation ?
You have two main choices:
If you want to continue to (directly) use a map created via Map.ofEntries() then you must avoid testing whether it contains null keys. Since you know that it cannot contain null keys, such tests are unnecessary.
If you want to rely on being able to test null keys' presence in your map, and especially if you want the option of having null keys or null values in it, then you must not use Map.ofEntries() to create it. You might, however, use Map.ofEntries() to initialize it. For example:
Map<String, String> myMap = Collections.unmodifiableMap(
new HashMap<String, String>(
Map.ofEntries(
Map.Entry("k1", "v1")
)
)
);
Note also that if you are putting fewer than 11 entries in your map, then Map.of() is a bit tidier than Map.ofEntries(). And, of course, if you don't care whether the map is modifiable then you don't have to put it into that unmodifiable wrapper.

This is implementation detail of the unmodifiable map, created by Map.ofEntries.
When you're adding null key to HashMap, it calculates hash of null equal to 0.
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
But Map.ofEntries creates ImmutableCollections.Map1 in case when only one pair was provided and ImmutableCollections.MapN otherwise.
Here is implementation of ImmutableCollections.Map1::containsKey
public boolean containsKey(Object o) {
return o.equals(k0); // implicit nullcheck of o
}
You can see that comment says that NullPointerException is expected behaviour. As for ImmutableCollections.MapN::containsKey it uses explicit null-check.
public boolean containsKey(Object o) {
Objects.requireNonNull(o);
return size > 0 && probe(o) >= 0;
}
If you refer Map::containsKey Javadoc, you can see that it's explicitly said that this method may or may not produce NPE.
Returns true if this map contains a mapping for the specified key. More
formally, returns true if and only if this map contains a mapping for a key k such that Objects.equals(key, k). (There can be at most one such mapping.)
Params:
key – key whose presence in this map is to be tested
Returns:
true if this map contains a mapping for the specified key
Throws:
ClassCastException – if the key is of an inappropriate type for this map (optional)
NullPointerException – if the specified key is null and this map does not permit null keys (optional)

Why does Hashmap allow a null key?

Actually I read lots of posts for this question, but did not get the exact reason/answer for "Why does Hashmap allow a null key?". Please can anyone give me the exact answer with an example?

One interpretation of your question:
why hashmap allowed [only] one null key?
Ask yourself: if HashMap allowed more than one null key, how would the map object distinguish between them?
Hint: there is only one null value.
Alternative interpretation of your question
why hashmap allowed [a] null key?
Because it is useful in some circumstances, and because there is no real semantic need to disallow it1, 2.
By contrast, with TreeMap null keys are disallowed because supporting them would be difficult given the implications of orderings involving null.
Given that the specified semantics for Comparable is to throw NPE.
Comparator is allowed to order null, but it is not required to. And many common implementations don't.
So if null was allowed with TreeMap, then the behavior of a map could be different depending on whether a Comparator or a Comparable is used. Messy.
1 - At least, that was the view when they specified HashMap in Java 1.2 back in 1998. Some of the designers may have changed their minds since then, but since the behavior is clearly specified it cannot be changed without messing up compatibility. It won't happen ...
2 - Support for null keys requires some special case code in HashMap which at least adds complexity to the implementation. It is not clear if it is a performance overhead for HashMap, since there would still need to be an implicit test for a null keys even if null keys were not allowed. This is most likely down in the noise.

Java engineers must have realized that having a null key and values has its uses like using them for default cases. So, they provided HashMap class with collection framework in Java 5 with capability of storing null key and values.
The put method to insert key value pair in HashMap checks for null key and stores it at the first location of the internal table array. It isn’t afraid of the null values and does not throw NullPointerException like Hashtable does.
Now, there can be only one null key as keys have to be unique although we can have multiple null values associated with different keys.
this link can answer more hashmap null key explained

The javadoc for HashMap.put clearly states:
Associates the specified value with the specified key in this map. If the map previously contained a mapping for the key, the old value is replaced.
It clearly states what happens when you do a put with a key which was already in the map. The specific case of key == null behaves in the same way: you can't have two different mappings for the null key (just like you can't for any other key).

This is still viewed as a mistake done in early implementations of HashMap that unfortunately people where (are?) relying on (as well as some particular order until java-8). The thing is, having this null key you could always pass some metadata along with your actual data "for free". Notice that all new collections ConcurrentHashMap, Map.of (in java-9), etc - all prohibit nulls to start with.

Null keys in Java collections that are not sorted

Can please someone explain me the following:
it is clear for me why null keys (values) are prohibited in Java sorted collections
But why they are not allowed in HashTable, ConcurrentHashMap and ... Properties
Does it relates somehow to thread-safety?
Is null value allowed/prohibited in CopyOnWriteArrayList? Why?
Thank you

There are 2 questions here. Both can be answered by reading the docs.
1 - Why HashTable, ConcurrentHashMap and Properties cannot receive "null" as a key?
HashTable:
https://docs.oracle.com/javase/8/docs/api/java/util/Hashtable.html
To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method.
ConcurrentHashMap:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html
Conversely, because keys and values in the map are never null, null serves as a reliable atomic indicator of the current lack of any result.
The Properties class extends HashTable, so you already got the reason.
2 - Is null value allowed/prohibited in CopyOnWriteArrayList? Why?
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
All elements are permitted, including null.
There is no further explanation on why is that, but I believe it's a design decision.

But why they are not allowed in HashTable
From the Doc:
To successfully store and retrieve objects from a Hashtable, the
objects used as keys must implement the hashCode method and the equals method.
of a null referenced object is impossible to get that information(because is null)
Is null value allowed/prohibited in CopyOnWriteArrayList??
from the source code
public class CopyOnWriteArrayList<E>
A thread-safe variant of java.util.ArrayList in which all mutative
operations (add, set, and so on) are implemented by making a fresh
copy of the underlying array. ...
....
.....
Element-changing operations on iterators themselves (remove,
set, and add) are not supported. These methods throw
UnsupportedOperationException.
All elements are permitted, including null.
some times it helps reading the doc:

How will I use JDK 8 Optional utility class to handle Null Pointer Exception for collections?

JDK 8 adds classes called Optional, OptionalDouble, OptionalInt, and OptionalLong that offer a way to handle situations in which a value may or may not be present. In the past, I would normally use the value null to indicate that no value is present. However, this can lead to null pointer exceptions if an attempt is made to dereference a null reference. As a result, frequent checks for a null value were necessary to avoid generating an exception. These classes provide a better way to handle such situations.
The first and most general of these classes is Optional.
It is important to understand that an Optional instance can either contain a value of type T(bounded type) or be empty. In other words, an Optional object does not necessarily contain a value.
Optional(value-based class) does not define any constructors, but it does define
several methods that let you work with Optional objects. For example, I can
determine if a value is present, obtain the value if it is present, obtain a
default value when no value is present, and construct an Optional value.
I tried something like this,
Optional<String> noVal = Optional.empty();
Optional<String> hasVal = Optional.of("ABCDEFGH");;
if(noVal.isPresent())
System.out.println("This won't be displayed");
else
System.out.println("noVal has no value");
if(hasVal.isPresent())
System.out.println(hasVal.get());
String defStr = noVal.orElse("Default String");
System.out.println(defStr);
But, i am unable to make out how to use it with collections so as to handle null? Can someone.

Your question lacks information about what you are actually going to do. Without a description of an operation, e.g. showing the code performing the action without using Optional, we can’t tell you how to do the same using Optional or whether this is possible at all.
One way of dealing with references which might be null is to construct an Optional via Optional.ofNullable(…). This can also be used within an action that is applied to Collection elements:
List<String> list=Arrays.asList("hello", null, "world", null);
list.forEach(x->Optional.ofNullable(x).ifPresent(System.out::println));
However, most operations on collections which you want to formulate using new Java 8 features are good candidates for the stream API. While forEach is suitable for a simple action, even the short detour via Optional makes it complex enough to benefit from the Stream API:
list.stream().filter(Objects::nonNull).forEach(System.out::println);
does the same without nested operations.
So Optional is a good return type for a single element which might be absent, e.g. like for Stream.findAny, but when processing collections, there are usually better alternatives.

Why is it useful to have null values or null keys in hash maps?

Hashtable does not allow null keys or values, while HashMap allows null values and 1 null key.
Questions:
Why is this so?
How is it useful to have such a key and values in HashMap?

1. Why is this so?
HashMap is newer than Hashtable and fixes some of its limitations.
I can only guess what the designers were thinking, but here are my guesses:
Hashtable calculates a hash for each key by calling hashCode on each key. This would fail if the key were null, so this could be a reason for disallowing nulls as keys.
The method Hashtable.get returns null if the key is not present. If null were a valid value it would be ambiguous as to whether null meant that the key was present but had value null, or if the key was absent. Ambiguity is bad, so this could be a reason for disallowing nulls as values.
However it turns out that sometimes you do actually want to store nulls so the restrictions were removed in HashMap. The following warning was also included in the documentation for HashMap.get:
A return value of null does not necessarily indicate that the map contains no mapping for the key; it is also possible that the map explicitly maps the key to null.
2. How is it useful to have such a key and values in HashMap?
It is useful to explicitly store null to distinguish between a key that you know exists but doesn't have an associated value and a key that doesn't exist. An example is a list of registered users and their birthdays. If you ask for a specific user's birthday you want to be able to distinguish between that user not existing and the user existing but they haven't entered their birthday.
I can't think of any (good) reason for wanting to store null as a key, and in general I'd advise against using null as a key, but presumably there is at least one person somewhere that needs that keys that can be null.

Well, I think Mark Byers answered perfectly, so just a simple example where null values and keys can be useful:
Imagine you have an expensive function that always returns the same result for the same input. A map is a simple way for caching its results. Maybe sometimes the function will return null, but you need to save it anyway, because the execution is expensive. So, null values must be stored. The same applies to null key if it's an accepted input for the function.

HashTable is very old class , from JDK 1.0.The classes which are in place from JDK 1.0 are called Legacy classes and by default they are synchronized.
To understand this, first of all you need to understand comments written on this class by author.
“This class implements a hashtable, which maps keys to values. Any non-null object can be used as a key or as a value. To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method.”
HashTable class is implemented on hashing mechanism, means to store any key-value pair, its required hash code of key object. HashTable calculates a hash for each key by calling hashCode on each key. This would fail If key would be null, it will not be able to give hash for null key, it will throw NullPointerException and similar is the case for value, throwing null if the value is null.
But later on it was realised that null key and value has its own importance, then revised implementations of HashTable were introduced like HashMap which allow one null key and multiple null values.
For HashMap, it allows one null key and there is a null check for keys, if the key is null then that element will be stored in a zero location in Entry array.
We cannot have more than one Null key in HashMap because Keys are unique therefor only one Null key and many Null values are allowed.
USE - Null key we can use for some default value.
Modified and better implementation of HashTable was later introduced as ConcurrentHashMap.

In addition to what answered by Mark Bayers,,
Null is considered as data and it has to be stored as a value for further checking. In many cases null as value can be used to check if key entry is there but no value is assigned to it, so some action can be taken accordingly. This can be done by first checking if key is there, and then getting value.
There is one more case in which just put whatever data is coming(without any check). All the checks are applied to it after getting it.
Whereas null as a key, i think can be used to define some default data. Usually null as a key does not make much sense.

Sir HashMap is also internally uses hashCode() method for inserting an element in HashMap, so I think this will be not the proper reason for "why HashTable allow null key"

It will make the Map interface easier to use / less verbose. null is a legitimate value for reference types. Making the map able to handle null keys and values will eliminate the need for null checking before calling the api. So the map api create less "surprises" during runtime.
For example, it is common that map will be used to categorize a collection of homogeneous objects based a single field. When map is compatible with null, the code will be more concise as it is just a simple loop without any if statement (of course you will need to make sure the collection does not have null elements). Fewer lines of code with no branch / exception handling will be more likely to be logically correct.
On the other hand, not allowing null will not make the map interface better/safer/easier to use. It is not practical to rely on the map to reject nulls - that means exception will be thrown and you have to catch and handle it. Or, to get rid of the exception you will have to ensure nothing is null before calling the map methods - in which case you don't care if map accepts null since you filtered the input anyway.