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?

Ah, very good

Test:
  doNotCompareStringsWithEqualEqualOperator

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

> Stack Trace
Completed in 2ms

Why invalidated?

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

invalidated

one of the worst design choices of java, frankly

I think we do. modifying the input is bad practice and the input might not even support that remove operation. Like all List of implementations.

Times out for me

Yes, that isn't defined, unfortunately

It is. Description says: Assume the second parameter will be a string holding one of two values: 'value' and 'index'.

So we don't have to consider other cases. That behaviour is undefined, we can return whatever.

It doesn't, because the input string is thread safe and we don't use member variables.