Thanks for reviewing Miguel, and yes - that was a small needle and a big haystack. :)
Miguel Figueiredo wrote:
Since we are in Java, the default behaviour of the == operator is memory address comparison. Seems that it's possible to overload operators for any object, but in the String class the '==' is not overloaded. It's strange how the committer let this go through, but he was right on the performance statement: it's faster to compare 2 string addresses than the actual content of the strings : ) I would say it's safe to revert.
It's actually not as bad as missing an '==' overload - in the Slide class PropertyName, all the String objects are interned in the constructor. The Java specification states that two interned strings a and b are guaranteed to give a==b true when a.equals(b) is true. So in theory it should work... See also: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#intern() and: http://www.javaworld.com/javaworld/javaqa/2003-12/01-qa-1212-intern.html My suspicion is that the background thread used for refreshing nodes in JNDIPrincipalStore (JNDIPrincipalStore$RefreshThread) is the culprit, and that the above statement for .intern() Strings is no longer true if running under multithreaded conditions in the JRE? It would be happy to get some clues as how to prove this, the only thing I could do in the end was to see that two PropertyName objects with the same namespace and name but different object references were not considered equal with "==" comparision. Anyhow, before someone can explain exactly why it happens I think that reverting the checkin is OK as long as the measured performance improvement was not a considerable amount. Also, I think that it is more safe to first have correct behaviour under all JRE conditions and then work on improving the PropertyName performance. Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
