ElementProxy initializes unconditionally the following > > static ElementChecker checker = new ElementCheckerImpl.InternedNsChecker(); > instead it should check a configuration option and initialize the appropriate subclass of ElementCheckerImpl. The default option should be .equals() though (change!). Users preferring == should be able to configure it that way. Correctness should trump optimization and even backward compatibility.
I have a fix for this on a local checkout. The problem is that there are many more pointer comparisons in the code-base, e.g. in the Canonicalizer implementations, and I'm not comfortable adding in a configuration option for these until I can test with a DOM implementation that does not intern namespaces. Is there a DOM implementation available in open-source land that either does not intern namespaces or allows disabling of interning via configuration? Colm.
*** Bug 47833 has been marked as a duplicate of this bug. ***
We also hitting this bug. As in the report https://issues.apache.org/bugzilla/show_bug.cgi?id=46888 we are using Weblogic 10.3 but under Linux with IBM JDK. This is a bug and should definitively be fixed. Please read the following article about interning and xerces: http://weblogs.java.net/blog/2006/06/26/all-about-intern Also when you look at the source code of the sun-jdk then you will notice the following in the String class: /** * Compares this string to the specified object. The result is {@code * true} if and only if the argument is not {@code null} and is a {@code * String} object that represents the same sequence of characters as this * object. * * @param anObject * The object to compare this {@code String} against * * @return {@code true} if the given object represents a {@code String} * equivalent to this string, {@code false} otherwise * * @see #compareTo(String) * @see #equalsIgnoreCase(String) */ public boolean equals(Object anObject) { if (this == anObject) { return true; } if (anObject instanceof String) { String anotherString = (String)anObject; int n = count; if (n == anotherString.count) { char v1[] = value; char v2[] = anotherString.value; int i = offset; int j = anotherString.offset; while (n-- != 0) { if (v1[i++] != v2[j++]) return false; } return true; } } return false; } so with a sun-jdk the equal call ends in a reference equality check, which will be true for xerces (as it does interning) and the overhead will be just a method call. I think other vm's will do the same, and if not then use another vm if you rely on this "performance gain". Interesting is also the documentation of xerces: http://xerces.apache.org/xerces-j/features.html under "SAX Features" they state that interning is disabled by default. I don't know if it's old doc, generally the case for DOM or just for SAX events. If that's true, then this is just a vm optimisation and a reason more to fix this.
It was decided to move to only using equals() so no configuration option is needed. See issue 40897.