Too much fun with EnumMap-related features and lambdas?

I have an utility class to handle EnumMap-related features, such as creating/converting between Object -> Enum and Enum -> Object maps. To better my understanding around lambda expressions in Java, I have used a great deal of streams, collectors and functions, and I'm not sure if I have gone too overboard...

• Is anything else I can make the code and unit test more Java-8-like?

• I am still using new EnumMap<>(...) and new HashMap<>() in certain parts of code, as I cannot seem to easily replace them with a Supplier type for the collectors. Is there anything I can do to improve this aspect? In other words, I will like to pass them into my doMap() method, instead of putting the newly created Map from the method call into my new EnumMap/HashMap instances.

-
I am using an Enum to represent the test cases, and then using TestNG's DataProviders to iterate through them. My motivations are:

• by overriding the toString() implementation, I have a fairly expressive way of providing descriptions for the test cases,

• they serve nothing more than a container for actual (or what I like to refer to as result) and expected values, and

• there is some practical elimination of duplicate @Test annotations and method declarations.

-
Are there any other downsides that I am not aware of, for choosing this non-conventional approach?

• Please review the Javadocs and the overall readability of the main and test classes too, as I will like to know if I am being too verbose in these departments.

EnumMapUtils

```
import java.lang.reflect.InvocationTargetException;
import java.util.EnumMap;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
import java.util.function.Function;
import java.util.stream.Collectors;
import java.util.stream.Stream;

/**
* An utilities class to handle {@link Enum}-related {@link Map}s.
*/
public final class EnumMapUtils {

public static final class DuplicateKeysExcep

I don't like validateArguments. I can't give you a definitive reason; I understand why it's there. It's certainly better than having all sorts of != null in all your other functions.

You throw IllegalArgumentException when I pass in null somewhere. But here's the catch.

I don't know that I passed you null. I gave you some sort of variable, and it comes from my pretty badly written code. And you say Illegal Argument!. I look through my code and I see nothing wrong.

Like a teacher who has too many tests to grade, I get a report back: My answers are wrong. I get an F. That's not good. Now I have to study the material again. I wish I knew what to study. Studying the whole material means I'll be busy all night.

If you said Illegal Argument! Null is not allowed! I'd have said "Oh yeah, that's right!" and been on my way.

I think you should either wrap a new NullPointerException() in your IllegalArgumentExceptions, or alter the message to contain "Null is not allowed!". Alternatively, take a look at Objects.requireNotNull(T object, String errorMessage): It validates for not null and allows you to pass a specific message.

I like the rest of the code. I read it thoroughly; All I'm wondering about is whether "over-riding" should be "overriding" instead.

StackExchange Code Review Q#63168, answer score: 7