I think I’m saying something slightly stronger than that. Interning provides two benefits:
- performance/footprint — not filling the heap up with a million instances of “” or “yes” - guarantees about String== — that it is safe to use == on String instances I believe the value of the second is rooted in a time when method invocation was so expensive that encouraging == in situations where the developer “just knows” seemed a pragmatic compromise. We’re nearly 25 years away from that world now, and we generally strongly discourage relying on == over equals for equality comparisons. (It is common to do `a == b || a.equals(b)`, in which case interning might push us through the fast path more often — for strings that are actually common. But this is more in the “can we intern” rather than the “must we intern” camp). As string literals get longer, the cost-benefit of interning get worse, and eventually turn negative; it is super-unlikely that two compilation units will use the same 14-line snippet of JSON (no benefit), and at the same time, we’re taking up much more space in the intern table (more cost). Surely today we’ll use Constant_String_info because that’s the sensible translation target, and if the same string appears twice in a single class, it’ll automatically get merged by the constant pool wrier. But committing forever to interning seems likely to be something we’ll eventually regret, without buying us very much. Even the migration benefit seems questionable. > Are you saying that the freedom to compile text blocks as > dynamically-computed constants (rather than as static constants; see JVMS12 > 5.1) is more important than the space savings and identity guarantees from > interning? I understand that starting off loose allows tightening later, but > the loose behavior is significant. > > Alex > > On 5/20/2019 4:46 PM, Brian Goetz wrote: >> I wonder if we want to be cagey about committing to interning, which >> is another way to say we must translate too a constant string info. >> In the future, alternate condy- based representations may seem >> desirable and we don’t want to be painted into a translation by >> overspecification. >> >> >> >> Sent from my iPad >> >>> On May 20, 2019, at 7:08 PM, Alex Buckley <alex.buck...@oracle.com> >>> wrote: >>> >>> Please see >>> http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html >>> for JLS changes that align with the JEP. >>> >>> Text blocks compile to the same class file construct as string >>> literals, namely CONSTANT_String_info entries in the constant pool. >>> Helpfully, the JVMS is already agnostic about the origin of a >>> CONSTANT_String_info, making no reference to "string literals". >>> Therefore, there are no JVMS changes for text blocks, save for a >>> tiny clarification w.r.t. annotation elements. >>> >>> Alex >>
