It's False. There are two 2s and one 3 so the correct array should be b = {4, 4, 9}, where {2**2, 2**2, 3**2}. Instructions below;

checks whether the two arrays have the "same" elements, with the same multiplicities. "Same" means, here, that the elements in b are the elements in a squared, regardless of the order.

Can you plz, explain what is the instruction missed here?

True, very hard to catch especially i had this when using https://www.ehcache.org/ ! very hard to spot especially on production

Correction: String.join does use the StringBuilder library, because StringJoiner uses StringBuilder under the hood. This means that String.join, StringJoiner, and StringBuilder are all O(n) optimal ways to concatenate strings, whereas the string concatenation operator + is O(n^2).

nCopies just returns a cheap List that contains the repeated element as many times as specified. String::join doesn't even use a StringBuilder, instead it directly builds the char array for the resulting String. It should be hard to optimize further.

In any case, optimizing for speed at the design level would be premature optimization. In production code, I'd expect code that's easy to read and understand even if it's not fully optimized, except when it turns out to drag performance down.

i think you should comment about the nCopies underlying implementation i assume its stringbuilder ! but hard to rate the performance
for called methods from collections without proper knowing how its implemented