Vendor library

From APIDesign

The simplest kind of library with a non-trivial proximity between the author of the API specification and author of the implementation is so-called vendor library. This kind of library is based on standardized specification. Usually multiple vendors with similar functionality sit down and agree on a specification. Each of them then provides their own different implementation. This was the case for EJB, JAX-RS, OSGi and possibly many others. On the other hand, it is almost always the case that there is only a single implementation of such specification in a running system.

DocumentBuilderFactory and SAXParserFactory are one of the most well-known examples of a vendor library. Especially in beginning of 21st century, people were trying to provide many different implementation of SAX and DOM parsers hidden beneath the common API. All such parsers however also packaged their own copy of the API (including the ones provided by the JDK itself) which worked, while one had just one such combo on in own application, but caused linkage problems when JDK continued to distribute DOM2 and there were modern parser and applications trying to use DOM3 (which contains incompatible interfaces from provider point of view).

All of this can be mitigated if one has good runtime support for modularity and this may be the reason why the vendor library seems to be very popular in OSGi world. The API part can request proper implementation and the OSGi container will select the right one. Especially with OSGi4.3 capabilities this seems very easy to specify and achieve.

The close proximity of the vendor of the implementation with the API (as they are packaged together) leads to so called Final interface design: TBD

After visiting OSGiCon I can see the value of this category, but yes, I have to admit I feel uneasy. But that is OK, people are supposed to feel uneasy when they have to accept new ideas.

Talk about: ModularLibrary with 1-N and N-M proximities.