Java API to query LDAP
The best API to use with Java is the UnboundID LDAP SDK. It's clear, complete, fully implements the LDAP standard specification, easy-to-use and understand, fully documented, thread-safe where it should be, and the standard edition is free. No other API even comes close.
see also
- LDAP Examples using the UnboundID LDAP SDK
Had to dive into Java LDAP SDK market, as some old LDAP JAVA programs with SDK bugs needed to be fixed and I had lost up-to-date overview of supported Java LDAP APIs for a while. A little research has brought me to several aged overviews and this rather old thread. I thought, I'd just share my more-up-to-date SDK findings here.
As of today, this is what the Java LDAP SDK market seems to offer:
jLDAP (Novell Java LDAP SDK), OpenLDAP Java SDK (sibling fork of Novell LDAP SDK), Netscape/Sun Java LDAP SDK, OpenDS LDAP SDK: All 4 repositories seem practically dead/unmaintained for several years (some of them for a decade now) now. No backing companies or active communities in sight.
Oracle LDAP SDK: Basically the former Netscape/Sun Java SDK with paid Oracle support, but otherwise not maintained either. Does not even exist in the open source world.
OpenDJ Java LDAP SDK: The backing company has moved away from the open source market, no longer maintain this SDK. The most recent SDK version 3.0.0 is already several years old and never left beta stage, the latest official release version is even older: 2.6.11. The commercial version of the SDK is said to be practically abandonned either.
ldaptive.org: some university project. A former JNDI wrapper, but now claims to have an own LDAP SDK protocol implementation. There seem to be no community or users outside of the university perimeter. Not dead, but currently unclear, what quality state to expect here. If you'd ask me, this project would have done a lot better, to spend their time backing the Apache LDAP SDK project, as no one actually needs yet another look-mom-I-also-made-an LDAP-Client-SDK in an a saturated market full of other mostly mediocre JAVA LDAP SDKs.
Apache LDAP SDK: Compared to other Apache projects, the LDAP SDK shows really slow pace. Somehow Apache LDAP seems to miss a real company backing things, it's only talented hobby enthusiasts pusing things forward. You probably do not want to start any new projects with SDK V1.0, as they state that V2.0 breaks interface code. but you probably also do not want to use SDK V2.0 yet, as it's still beta and no one knows for how much longer it will stay beta (V1 stayed beta for 6 years...). The SDK is far from being dead, it's just showing really really slow progress.
Java JNDI: Built into Java since ages and has not changed since release. Still is really ugly for coding, documentation is a mess, every task beyond basic search is an implementation nightmare, basically every project fails to properly implement it, several things are broken by design. There seem to have been a few concept ideas of a JNDI-LDAP-successor for a future JDK, but nothing has ever followed so far.
Unbound SDK: Mature, best maintained SDK, has huge amount of features, though the backing company is still nurtured from venture capital, burning money. So far it does not look like they stand on their own feet any time soon. So the long term aspect of SDK backing support is unclear. A former party pooper for the SDK in commercial projects once was its GPL license. The open source version now seems to have a LGPL license as well (that may or may not fit a project).
Spring: seems like a stable LDAP SDK, plus has the large Spring community. But less feature-rich and no bleeding edge stuff. Personally no experience yet though with this SDK.
So right now, Java LDAP seem to have a reasonable choice of four: JNDI, Unbound, Spring, Apache, each with their pros and cons. And you probably will hate JNDI a lot, as soon as you start using it. A good advice might be, to not rush into migration projects of old SDKs and to invest into the extra effort of implementing wrapper code, to be at all able to easily switch the SDK later when needed.