Absolutely! I've only earned a couple hundred thousand dollars from my operational experiences with JLDAP. Unfortunately, besides Marc those many other voices don't speak much about the Java LDAP code anymore, neither here nor at Novell's mailing JLDAP list. You yourself have said more about my work in your concise responses over the years than any of them. Hence, I've become accustomed to living in feedback deficit.
I do have to say this is a consistent problem with JLDAP. I like it far more then JNDI but it just doesn't seem to have much adoption. At one point Sun was talking about adding an LDAP api like JLDAP to Java, but when I brought up JLDAP or even the Mozilla stuff it went no where. That list has been pretty quite for the last few months, and with the turmoil over at sun around OpenDS I wouldn't hold my breath.
And as for Marc's plan to change the toString() method to return "", I would have preferred the approach Michael implied where null means an undefined instance and "" is the RootDSE (an honest-to-god node in the DSE). I'll have some time, so I'd be happy to clean up the whole class over the next few weeks if nobody objects (and if my privileges are still valid?).
Hmm, while I appreciate the argument about 'new DN("") == RootDSE' from a conceptual standpoint, from a pure Java standpoint I don't think its proper for an initialized object to return null from toString(). I can't think of any examples that do this in Java and I can say that returning null from toString() has caused me no end of heartburn over at MyVirtualDirectory. I would much rather have RootDSE be a constant on either LDAPConnection or DN then have null returned from toString(). As null is not a String I don't think its an accurate String representation of the DN class or an instance of it. So for both the pure Java related reasoning above and the wording of the RFC (as well as the feedback from the other java based ldap projects) I feel returning "" from toString is really the only way to go.
Jon, by 'Clean Up' what do you mean? To be honest my issues are less with the DN class its self and more with its inconsistent use in JLDAP (ie the Entry class takes a String for its DN and returns a String as well). I could think of a few new features (ie a bit more control over the RDNs).
Thanks
Marc
Jon Roberts www.mentata.com