Re: Problem with PropertyName equals() when using JNDIPrincipalStore

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