Marc Boorshtein wrote: 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: 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. 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: 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. 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: 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. 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. 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. That's a thought. Or as I said if it's uninitialized then it's the RootDSE, period. That would be a documentation fix. I'm satisfied. Like I said, I have yet use the call anyway. 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. 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. 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