Archie Cobbs wrote: > Santiago Gala wrote: > >> IIRC, the (JVM spec v2) requirement for .equals String literals to be >> (==)identical only holds for Strings in the same .class file, but I >> could be wrong. > > > I believe the requirement is stronger than that. Any two > String literals (i.e., String constants from class files) > that are the same string must be the same object (==). > It doesn't matter if they come from different classes.
I agree. All identical string literals must refer to the same instance. http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#73272 >> In any case, interning all VM Strings in some sort of global weak set >> would do the trick, as shared literals would remain referenced on >> classloader collection, while unreferenced ones would be eligible for >> collection. This is typically how symbols in lisp or smalltalk are >> managed (most implementations don't even bother to use a weak structure, >> so symbols are never collected). Basically this is what String.intern() >> does, and nothing impedes us to actually use it for all Strings in the >> VM. > > > This is how Classpath works. Strings are intern'd using a weak > hash map and String.intern() is implemented in pure Java. > The JVM does nothing special for strings, with the exception > that when it creates them from class files it also interns them. I'd speculate that the VM interns many more strings loading classes than typical Java code calls to the API, so provided the call into Java is low-cost this works fine. > -Archie > > __________________________________________________________________________ > Archie Cobbs * CTO, Awarix * http://www.awarix.com > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
