Disallow invocations of java.lang.String.intern()

[carterkozak]

What happened?

String.intern sounds great, the javadoc describes exactly what we want: a canonical representation of a string value.
Unfortunately it's too good to be true, and has serious performance penalties, described here: https://shipilev.net/jvm/anatomy-quarks/10-string-intern/

What did you want to happen?

We have several alternatives for similar functionality, including Guava Interners, java9+ compact strings JEP 254, and G1 string deduplication JEP 192

Given arcane sharp edges of String.intern, and benefits of the alternatives, we should not allow String.intern.

[robert3005]

Since java 7u40 interned strings are garbage collected so unless you're using CMS there's nothing wrong about them. There's also ongoing work in shenandoah to make string table evictions part of the concurrent phase which would eliminate the pause he's talking about in the article. Overall though if you want to intern strings it's the most memory efficient option you have though might not be the most performant.

[carterkozak]

Sorry for the delay!

Failure to GC interned strings is only one aspect, overflowing the fixed size native hash table results in degraded performance, and the native invocations themselves are expensive in the best cases, and result in the jvm being unable to optimize code in ways that it would around java maps.

While there are scenarios that string.intern may be more efficient than java-based implementations, it's incredibly difficult to maintain over time. Intern has sharp edges that I don't expect most developers to be aware of. I don't believe there's enough real world benefit to using string.intern over other options to be worth that risk in the best cases.

This check should be similar to DangerousThreadPoolExecutorUsage and may be suppressed if you're certain that you know what you're doing, but provide quick automated feedback to developers who may not be aware of the dangers.