Marc Boorshtein wrote:

I wanted to get an opinion from the other java ldap projects. Should the toString() method of a class that represents a DN return null or an empty string? I would think an empty string but JLDAP returns null. Anyone have an opinion on the matter?

I'm not a Java programmer but in Python one has also to distinguish such cases ("" vs. None).

It really depends on what you want to express. Note that "" represents the rootDSE or root naming context. So "" would reference something existing or well-defined. IMHO NULL (or None in Python) would better signal something undefined or none-existing.

Ciao, Michael.

Michael Ströder wrote:

Marc Boorshtein wrote:

...

I wanted to get an opinion from the other java ldap projects. Should the toString() method of a class that represents a DN return null or an empty string? I would think an empty string but JLDAP returns null. Anyone have an opinion on the matter?

Not a strong one, since I don't make use of DN.toString(). In my view the DN utility class is for deconstructing, analyzing, and comparing non-trivial distinguished names... I invariably have the string version to begin with.

It really depends on what you want to express. Note that "" represents the rootDSE or root naming context. So "" would reference something existing or well-defined. IMHO NULL (or None in Python) would better signal something undefined or none-existing.

This was my first thought, but according the source as I read it these cases would not be distinct: if there are no parent RDNs superior to the entry reflected in the represented DN, toString() will return null.

Since there is a no-argument constructor DN(), perhaps the original thinking was that null and the rootDSE "" are synonymous. On the other hand, the existence of this constructor makes as much sense to me as the redundant addRDN() and addRDNToFront() methods (ie. none at all). I suppose *somebody* may want to build a DN instance iteratively, but I would consider it easier to do so concatenating strings for submission to the more relevant constructor with argument.

This exercise in software archeology underscores a major reason I think JLDAP is latent: a lot of cruft but nobody of original authorship to explain or clean it up. As for the rest of us, if nobody touches it nobody breaks it, so there it sits. My 2c.

Jon Roberts www.mentata.com

Howard Chu wrote:

Jon Roberts wrote:

...

Since there is a no-argument constructor DN(), perhaps the original thinking was that null and the rootDSE "" are synonymous. On the other hand, the existence of this constructor makes as much sense to me as the redundant addRDN() and addRDNToFront() methods (ie. none at all). I suppose *somebody* may want to build a DN instance iteratively, but I would consider it easier to do so concatenating strings for submission to the more relevant constructor with argument.

Sounds like someone was making a (perhaps futile) stab at instilling the concept that DNs are honest-to-god sequences of structured data. A good goal, at least.

I agree, and as I said I can see where somebody would use that idea. The pointless constructor and redundant methods are still bad. I would guess the OpenLDAP C code does not contain many examples of procedures with different names that do the exact same thing line for line, but I could be wrong.

...

This exercise in software archeology underscores a major reason I think JLDAP is latent: a lot of cruft but nobody of original authorship to explain or clean it up. As for the rest of us, if nobody touches it nobody breaks it, so there it sits. My 2c.

Keep putting in your 2c. It obviously needs more feedback from more people with real operational experience using it.

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.

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?).

Jon Roberts www.mentata.com

Marc Boorshtein wrote:

...

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.

Back in the earliest days of the Netscape Java LDAP libraries, it seemed Sun viewed the approach as competitive rather than complimentary (ditto Linux). I'd like to assume times have changed. I wrote the OpenDS project lead a long message on the subject of Java LDAP earlier this year and was ignored. I'm naive to any turmoil, and I don't hold my breath for anything anymore.

I personally think the best solution to revitalizing JLDAP is for those of us that care to clear the outstanding ITS reports and then refactor what's there as a way to assume a sense of ownership within the OpenLDAP project. I'm not suggesting taking anything from Novell or making radical changes; more like a systematic review that gives new blood some skin in the code base. I mean JLDAP has classes that have been deprecated for five years now.

Better yet would be to follow the OpenLDAP development model and start a new branch for a new version (e.g. 2.3 to 2.4). That would be huge though, so the breath holding heuristic again applies.

...

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 DIT). 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 do agree, but what I said originally is that the class permits the construction of an uninitialized DN for whatever reason. My thinking is always that if null is a possible state, it should be a possible outcome.

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.

Now that's an argument I can understand, yet I'm not familiar with MyVirtualDirectory. Why does it have the potential to call toString() on uninitialized DN instances? Is it a matter of checking for null in lots of places? Is the problem inherent to something external like use with J2EE? I'm not debating the point, I'm just curious.

I would much rather have RootDSE be a constant on either LDAPConnection or DN then have null returned from toString().

That's a thought. Or as I said if it's uninitialized then it's the RootDSE, period. That would be a documentation fix.

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.

I'm satisfied. Like I said, I have yet use the call anyway.

Jon, by 'Clean Up' what do you mean?

I'd have to look deeper to answer, but deprecating/removing the redundant methods for a start. I was really just thinking this class would be an ideal place to start refactoring because it's utility, peripheral, and concise. PoolManager would be another one, because it has bugs to boot. That's where I was headed just before my personal life got sent through the meat grinder.

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).

As I said, I use the DN class to parse distinguished names where I need to, but Strings are the currency for most of my program logic. On the other hand, I would definitely see the value of alternate methods to take and return DN values wherever possible. It wouldn't be that difficult.

I could think of a few new features (ie a bit more control over the RDNs).

Right. I was thinking something could be done here too. Like I said, I'd have to take a longer look than I did.

I don't know what your current time constraints are. As I've said, mine aren't pretty. I remember before you didn't have much to give. Regardless, I think the two of us at least should start a more concerted effort in this vein at whatever pace we can afford. Anything is better than watching this nifty library wither from neglect.

Feel free to reach me off-list.

Jon Roberts www.mentata.com