santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45637] Add configuration option for == vs .equals() String comparisons
Date Tue, 02 Mar 2010 10:17:20 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45637

--- Comment #3 from Marc Giger <gigerstyle@gmx.ch> 2010-03-02 10:17:18 UTC ---
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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message