Hi Nils
The idea would have been that you get the Handler by using
org.apache.fop.apps.Fop.getDefaultHandler() not by working directly on
the FOTreeBuilder:
https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/Fop.java
Any particular reason why you chose this
Sounds reasonable to me--I think I should have done the validation that
way to begin with (IIRC =='s are Not Good with Strings anyway for the
very reason you gave.) I am surprised this problem did not occur
before. I'll make the change next.
I am personally pleased that FOP 1.0 is now
Andreas L. Delmelle wrote:
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Committers, I don't see a problem with what Nils proposes. Does anyone
else? If not, I can do the change next week. If Nils already has a patch
for us, even better. :-)
Well, the whole
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
snip /
Another option: validateChildNode() is called from only one place,
FOTreeBuilder.startElement(). At that point, we can also feed vcN() the
parameter namespaceURI.intern() instead of just namespaceURI.
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
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Hi,
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 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
I've seen such a warning in another FO implementation and thought this
woud be a nice service for our users. I didn't give the implications
much thought. Should I remove the check?
On 26.06.2005 16:13:39 Glen Mazza wrote:
BTW, Jeremias--the recent warning you added to the
code on ignoring an
Hi
thanks for the quick response from everyone.
Sounds reasonable to me--I think I should have done the validation
that way to begin with (IIRC =='s are Not Good with Strings anyway
yes, I think so as well. Since String.equals() does the == check
first anyways there shouldn't be a
