5 ms·

You should compare the cost of one (or two) .intern() plus '==' against a single .equals() For example, if your code needs 10 .intern() and then performs 100 '

You should compare the cost of one (or two) .intern() plus '==' against a single .equals() For example, if your code needs 10 .intern() and then performs 100 '==', that is possibly going to be faster than performing the equivalent 100 .equals() (or maybe not) But if you are comparing a single couple of strings, .equals() is always going to be faster. Not to mention that if you .intern() random strings, you risk running out of PermGen space. Even in the case of 100 comparisons among 10 strings, you may be better off using a custom HashMap. You can find all this information in the article.

derriz 9y ago
I'm not suggesting that .equals() should be implemented by 2 inter() operations followed by a reference comparison. But that the implementation check whether the pair of Strings happened to be already .intern()ed, and then use the short circuit of a reference comparison. A programmer could then decide to intern _some_ non-constant Strings in their application if it made sense (i.e. they were frequently used in comparisons or as hash keys). And I don't think you can't run out of permgen as the String pool is a fixed size - unless I am misreading that section of the article. However now that I've thought about a bit more, I think the flaw in the idea is unrelated to your points but that currently it's not cheap to determine if a particular String is interned. The StringTable implementation would have to be changed otherwise it would require adding storage overhead to every String which would not be acceptable. This is also probably why .hashCode() doesn't memoize it's results.