The decision to disallow null keys and values in ConcurrentHashMap stems primarily from the desire to avoid ambiguities and potential concurrency issues. Here’s a breakdown:

1. Ambiguity with get():

• If ConcurrentHashMap allowed null values, the get(key) method would have an ambiguous return. A null return could mean:
  • The key does not exist in the map.
  • The key exists, and its associated value is null.
• In a concurrent environment, this ambiguity becomes particularly problematic. Checking with containsKey(key) before get(key) is not reliable, as another thread could modify the map between those two calls.

2. Concurrency Concerns:

• Concurrent maps are designed for thread safety. Allowing nulls would introduce complexities in maintaining this safety.  
• The design of ConcurrentHashMap aims to provide efficient and predictable behavior in concurrent scenarios. Null values would make these goals harder to achieve.

3. Historical Context and Design Decisions:

• The design of ConcurrentHashMap was heavily influenced by the need to avoid certain pitfalls that were recognized in earlier map implementations.
• It is also worth noting that the design of Concurrent hash map was done by Doug Lea, and that there were design decisions made to simplify the code, and to make it as efficient as possible.  
• There is a general trend within modern Java APIs to discourage the use of nulls, and to instead use other methods of expressing the absense of a value, such as the use of Optional objects.

In essence:

• By disallowing nulls, ConcurrentHashMap simplifies its internal logic and provides clearer, more predictable behavior for concurrent operations.
• It removes the ambigutity of the get() method.