In defineclass.cc, we do a pass over the constant pool and turn JV_CONSTANT_String references into _Jv_Utf8Const objects. Later, during linking, these are turned into real String instances. We could just as easily create real Strings when defining the class and reduce the amount of work to be done during linking. On the one hand this involves more space overhead for classes which are not used (most string constants are ASCII, which is represented more compactly in a Utf8Const). On the other hand, the utf8const is garbage after linking, some String constants are common (these are always interned, so these would be shared), and usually string constants are short anyway (so the savings is probably not significant).
Is this related to PR 1259 at all?
I think PR 1259 relates to deficiencies in the compiler, not the runtime (or at least not this part of the runtime). This PR refers to a minor possible optimization when defining an interpreted class; it doesn't affect whether or when other classes are initialized.
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.