On 29/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Still, we need to have this functionality, because it is in spec.
True, intern() is part of the spec, and GC-intern() will be much better :-)
> However, by hard-coding the message like this, you're > guaranteeing that the VM will intern() the string "how are you?", even > if it never prints this message out (because it's in the constant > pool). This is not the case, at least for DRLVM (I do not know about other JVMs). The string literal in the .java file is compiled to the constant pool entry in the class file, and essentially, the whole contents of the class file is loaded to memory (native memory). No java object instances are created at this point.
The memory (for the message key) is still taking up space in the constant pool for the class, though as part of the class loading process. From what I've seen, message keys tend to be longer than the equivalent field names (also stored in the constant pool). And that's before the String instance is created.
We may consider the opportunity to save memory by not keeping the class file contents in memory, and loading it on demand, but I personally do not know for sure how is it done now.
Neither do I :-) It might only load constants from the constant pool on demand, but my expectation is that the whole class's contents are loaded into memory from whatever storage container (e.g. Jar) that they came from. Perhaps the constants could be optimised in some kinds of ways e.g. by writing them out to a memory mapped temporary file.
The java specification does not require eager loading of the string literals, and DRLVM in fact does not do it.
Interesting. Perhaps I misunderstood the spec, but I was under the impression that all String literals were interned like this. Perhaps it's just because I've seen examples such as: private static final MESSAGE_HELLO_WORLD_KEY = "hello.world"; which, of course, would be assigned when the class is loaded (and thus the string literal interned approrpiately). Lazy instantiation of such keys would delay this behaviour.
It only keeps space in class file if it is never used. Saving space on class loading is a separate issue, not related to strings interning.
I think that they are related; but only in that the context of internationalisation of messages and message keys is often where the intern() is used (especially with respect to the way message key is initialised). However, the relationship is not symmetric; it's possible to discuss intern() without reference to any kind of message keys.
> Importantly, it explains why the Eclipse NLS class uses static string > variables to refer to messages, and not to String literals for exactly > this reason. If you use a static string variable that is dynamically > initialised from a properties file, you only take the memory up when > you need to refer to that message actually, I think, this should read "... when you need to refer to any of messages contained in the resource bundle ..."
True, the class loading will cause all messages in the same messages class/file to be loaded at once. (Bundle might be misleading here; an eclipse bundle/plug-in often has one messages class/file, but may have several.)
The interned strings design does not precludes from garbage collecting interned strings. The patches I've sent in fact do just that.
Yes, this sounds like a good plan.
> In other words, all of the benefits of intern(), and yet none of the > disadvantages. Remind me again why we're not using this method for > doing messages in Harmony? The Eclipse approach for localizing messages from java code looks promising, but requires some work duplication or complex tooling support. As far as I understand, Eclipse approach is completely orthogonal to traditional localization approach, so it imposes no restrictions on using two approaches simultaneously. Feel free to submit patches to use it :)
Yes, it should be possible to use this too. Eclipse also has tooling to search for string literals and propose replacements for them automatically ... http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/documents/3.1/message_bundles.html http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/tasks/tasks-188.htm http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/reference/ref-wizard-externalize-strings.htm The only issue might be that Eclipse uses an NLS class to do the in-lining of messages, so we'd either need to re-implement or to re-use the Eclipse NLS file directly. I think that discussions following on re: internationalisation should continue in the new thread created for that purpose. Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
