Jeremias Maerki escribió:
On 26.06.2005 14:41:13 Glen Mazza wrote:
<snip/>
Well, the whole idea behind using interned strings and the == operator is
speed.
As you both are probably well aware, using .equals() on interned strings is
a lot slower than comparing them with ==.
Not necessarily--I suspect implementations of .equals() probably first
check if they == each other, and if so quickly return true before trying
a character-by-character compare.
Glen is right. java.lang.String.equals() checks "==" as the first
statement. So this change shouldn't have a big impact on performance. It'
just an additional method call (which might even be inlined by the JIT).
Jeremias Maerki
Thanks for checking. BTW, Jeremias--the recent warning you added to the
code on ignoring an span attribute on an fo:static-content descendant.
Keep in mind, it may end up *not* being ignored for three reasons: (1)
layout may someday allow fo:static-content to be redirected to the
fo:region-body (where span values become relevant), although FOP
currently raises an error when that occurs; (2) There are some XSL
functions which allow you to reference the property value on that FO;
and (3) the span attribute could be inherited by
fo:instream-foreign-object that an fo:block encloses. Personally, I
think this warning is not really needed (it is a given from the spec
that multiple columns aren't supported in side regions), or would better
be placed in layout (query the span attribute from SCLM and complain if
not "1" or "all".)
Glen
