Quote:

---

I think he might be referring to the part about how String literals are maintained in the defining class. I understand that the .class file has a string literal table in it, but does the specification say that string literals in different classes will be different?

---

No it doesn't say that precisely. String literals in different classes that are loaded at the same point in time can never be different instances. This is a language spec requirement. String literals in different classes whose life scopes are disjoint may be represented by different string instances -- this is precisely what is shown by the second code snippet in the article.

Furthermore, just to cover all bases I will mention here (and perhaps this should have been mentioned in the article) that the constant_pool segment in a .class definition (as detailed in the section 4.4. of the JVM spec) has nothing to do with the interned string pool that might be used natively by the JVM to implement String.intern().

The former is the standard format for how classes are compiled and how class bytecode is loaded by the JVM. Once the bytecode is loaded, the .class definition is discarded and is instead represented internally in some native data structures that are likely very different from .class layout.

In fact, the constant_pool is allowed to contain duplicate CONST_String and CONST_Utf8 entries for the same string content. (It normally does not happen because compilers and common bytecode manipulation kits usually merge such duplicates into a single entry per unique value {primarily because .class layout was designed with compactness in mind}, but it is not forbidden by the spec). A simple experiment will show that a class with duplicate CONST_String entries in its constant_pool will be loaded without any problems and it will not affect String.intern() in any way.

So, the two things (constant_pool in every .class and String.intern() value pool) are completely independent entities. The first one is just a data layout that enables Java's dynamic class linking, the second one is what really implements String.intern() behavior at runtime.

Post Extras