I used it a few times for great effect, many years ago, when dealing with very data heavy Swing applications. We dealt with millions of rows of data, and some k

I used it a few times for great effect, many years ago, when dealing with very data heavy Swing applications. We dealt with millions of rows of data, and some keys were strings with very low cardinality. Interning some of those columns lead to major reductions in memory usage: Tens of millions of copies of the same string aren't all that great for 2005 era laptop, as headroom between garbage collections, especially back in the day, could make a big difference. Now, the fact that the strings were comparable with == vs .equals? never bothered trying to play those games. Now, could we have solved this with other ways other than interns? Absolutely: Just make deserialization code do mostly the very same thing, but done by hand and on the heap. In today's JVM, if you are using the G1 garbage collector, you can get 99% of the memory savings almost completely for free with a VM parameter: You still pay for an extra object, just pointed to the same character array underneath. I'd argue it's one of the most underutilized flags out there: It's not uncommon to end up with half the memory footprint in many use cases, and memory savings are often runtime savings too. Now that we have this, maybe intern always loses, but it was definitely useful in the right circumstances.