Because you're doing something entirely different, I'm asserting, you're testing. The equivalent java code would be:
return superSet.containsAll(actualSet);
But a straight up boolean doesn't tell me what is missing, only that something is missing. I snipped out the bit about creating a more verbose exception creation because it wasn't really needed for the example:
if (missing.size() != 0) {
final StringBuilder builder;
builder = new StringBuilder();
builder.append("Missing item found: [ ");
builder.append(String.join(",", missing.stream().map(x -> x.toString())).collect(Collectors.toList())));
builder.append(" ]");
throw new IllegalStateException(builder.toString());
}
Keep in mind that the objects that this method was written for actually implement human readable toString methods.
> What's with the "final"?
Habit that I forced on myself. But it's not a bad habit to get into. In theory methods are supposed to be short and readable but reality often ends up being that in the fury of writing under looming deadlines you can have horrifically long methods that do many things. And I've seen more then a few times someone reusing variable names badly. Using final when possible is just a way for someone to be able to look at the code, see the variable name and be able to know that what it says is what it is.
>And why do I have to type out obvious types in 2019
Because types aren't always obvious. That's a list, meaning that you can have duplicated items and that order matters. What if my 'list' was actually a set, in which order was not guaranteed? What about if you're trying to integrate this with multiples teams scattered across the world that don't speak English on a code base that's about 500,000 lines of code? Or when you walk away for 2 or 3 years and then have to come back to a method that's not as small and trivial as the given example? What about the next poor sap that has it dumped in his lap?
I know it seems stupid in the short run, and if you've got something small or something that probably wont' be relevant in a year or two, and I'd agree with you if that's the case. But but if you've got a code base that needs to be communicated to other people, then typing is a good way of handling that communication without having to write extra documentation.