Sorry, but I have to take a step back here and withdraw from this
discussion. This nit is taking too much of my attention. It works, so
I'll leave it be, although I'm not fully comfortable with the presence
of the intern() calls. It works just fine locally without them and I
can't imagine a big
Thanks to Finn and Andreas for looking at this. Given what I see here
I'd say the two intern() calls in FOTreeBuilder would better be removed.
The Set the namespaces are stored in works with equals() anyway, so I
don't see the point of interning the Strings. Or do I miss anything here?
On
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
But since == *is* faster then .equals and I think we can assume that
most URIs are in fact from the FO namespace we can get the benefit from
both.
Measured with jdk1.4.2_02 on winXP:
Equal string
== 141
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
But since == *is* faster then .equals and I think we can assume that
most URIs are in fact from the FO namespace we can get the
I don't think the discussion was finished when you did this, Glen.
Anyway, I've looked up our use of String.intern() in our sources and the
only use is with namespace URIs (see FOTreeBuilder). I believe the
intern() call there doesn't help a lot here concerning memory
consumption. If the XML
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
... So I believe Nils proposed change doesn't have
any negative effects, especially since we don't seem to have pursued a
more widespread use of String.intern() back when it was discussed in
December 2003
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
snip /
Oh no, it wasn't--but we know the status quo *wasn't* acceptable, and
that the performance argument was no longer valid because of the
research you did on .equals(). Now you and Andreas can finish out the
