Your new solution will pass the tests, and I completely agree that it will not be based on luck. However you did not call String.intern() in the current solution we are discussing, so that one is wrong. Your example does prove that my wording was too absolute: yes, it can be OK to compare string objects with == if you know precisely how the language works and you took the necessary precautions beforehand, it was the general case I had in mind.

One way they can learn is trying == and failing tests.

Your argument assumes that they will browse the solutions, stumble upon yours, and then read the comments. I would rather assume that most will not do this, and that it's better to catch offending solutions within the tests.

Strictly speaking, for this particular case, I do not think it's about best practices vs. poor practices. Best practices are somewhat debatable and cultural - they are a set of programming rules that many experienced developers have reckognized to be preferable, i.e. they are based on consensus and experience and not always unanimous.

Comparing strings with == in Java is not poor practice, it is semantically incorrect and will fail sooner or later. Solutions that do it only pass due to happenstance. For a popular kata like this (almost a thousand solutions in Java) that inevitably involves string comparisons, I thought it was worth it to add a specific test for that. I did the same some time ago in the kata A needle in the haystack. There are 17,000 Java completions there and likely thousands of them have if (haystack[i] == "needle") (only about a hundred are flagged as invalidated because it's too costly to re-test such a huge amount of solutions), proving that it is a very common mistake that is worth being tested against.

Probably 90% of my solutions could be categorized as "not a good idea", so those deserve to have very low votes for "Best Practices".... like this one already has.

How will beginners learn about the String Pool unless they see unexpected solutions like this, along with all the user comments explaining why == is NOT a best practice?

Test:
  doNotCompareStringsWithEqualEqualOperator

Should return true expected:<true> but was:<false>

> Stack Trace
Completed in 2ms

sorry, can't let beginners think it's a good idea :(

invalidated

one of the worst design choices of java, frankly

touche

Oh, I didn't know about the difference. Thanks for that.

Thanks for the input.

Quite fair! Luckily the test cases ignore invalid characters for me.

The expected return type could be Collection<String> though to allow Lists, Sets and what not... But it's not a big deal.

No, I doubt it would be more efficient.

... :o
mmmh, don't you think...?

• generates duplicates
• consume time to order the set or even compute the hashcodes if you use a classic set

against

• generate every possibility one and only one time
• generate already in correct order.

I guess you need to clear your mind a bit...

The contract is a list to be consistent with the original language too. Don't forget that.