Vendor library
From APIDesign
| (3 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
The [[API]] for [[XML]] processing in [[Java]] (with entry points in {{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}}) is one of the most well-known examples of a [[vendor library]]. Especially in the beginning of 21st century it was a common hobby among many programmers to write own implementation of an [[XML]] parser. Often the implementation was hidden behind the facade of SAX or [[DOM]] [[API]]. Such parsers also package their copy of the [[API]] (as providers of [[vendor library]] are supposed to do). | The [[API]] for [[XML]] processing in [[Java]] (with entry points in {{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}}) is one of the most well-known examples of a [[vendor library]]. Especially in the beginning of 21st century it was a common hobby among many programmers to write own implementation of an [[XML]] parser. Often the implementation was hidden behind the facade of SAX or [[DOM]] [[API]]. Such parsers also package their copy of the [[API]] (as providers of [[vendor library]] are supposed to do). | ||
| - | The close [[proximity]] of the vendor of the implementation and the [[API]] (as they are packaged together) leads to so called [[final interface]] design. This kind of design caused heavy nightmares as soon as the [[XML]] parsing [[API]] become part of [[JDK]] and as soon [[DOM]]2 was evolved into [[DOM]]3. These problems lead me to conclusion that [[final interface]] is a total anti-pattern (also expressed in [[chapter 7]] of [[TheAPIBook]]) and we (me and others in the [[NetBeans]] project) invested a lot in | + | The close [[proximity]] of the vendor of the implementation and the [[API]] (as they are packaged together) leads to so called [[final interface]] design. This kind of design caused heavy nightmares as soon as the [[XML]] parsing [[API]] become part of [[JDK]] and as soon [[DOM]]2 was evolved into [[DOM]]3. These problems lead me to conclusion that [[final interface]] is a total anti-pattern (also expressed in [[chapter 7]] of [[TheAPIBook]]) and we (me and others in the [[NetBeans]] project) invested a lot in inventing a [[Modular library|better alternative]]. [[OSGi|Other people]] however had different opinion and invested a bunch of energy to find out under which conditions [[final interface]] is an acceptable pattern. |
| - | After visiting [[OSGiCon]] in 2012 and having few chats with folks like Peter Kriens I can confirm I see the value of [[vendor library]] [[proximity]]. | + | After visiting [[OSGiCon]] in 2012 and having few chats with folks like [[Peter Kriens]] I can confirm I see the value of [[vendor library]] [[proximity]] now. I can understand [[OSGi]] better. I could almost say that [[OSGi]] has been designed to make [[final interface]] a [[good]] design pattern. However one has to keep in mind that this [[API]] design style works well only with [[vendor library|One to Many]] (and possibly [[Semantic versioning|Few to Many]]) [[proximity]]. As soon as [[Modular library|Many to Many]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|more flexible design]]. |
| + | |||
| + | [[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Evolution]] | ||
Current revision
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.
The API for XML processing in Java (with entry points in DocumentBuilderFactory and SAXParserFactory) is one of the most well-known examples of a vendor library. Especially in the beginning of 21st century it was a common hobby among many programmers to write own implementation of an XML parser. Often the implementation was hidden behind the facade of SAX or DOM API. Such parsers also package their copy of the API (as providers of vendor library are supposed to do).
The close proximity of the vendor of the implementation and the API (as they are packaged together) leads to so called final interface design. This kind of design caused heavy nightmares as soon as the XML parsing API become part of JDK and as soon DOM2 was evolved into DOM3. These problems lead me to conclusion that final interface is a total anti-pattern (also expressed in chapter 7 of TheAPIBook) and we (me and others in the NetBeans project) invested a lot in inventing a better alternative. Other people however had different opinion and invested a bunch of energy to find out under which conditions final interface is an acceptable pattern.
After visiting OSGiCon in 2012 and having few chats with folks like Peter Kriens I can confirm I see the value of vendor library proximity now. I can understand OSGi better. I could almost say that OSGi has been designed to make final interface a good design pattern. However one has to keep in mind that this API design style works well only with One to Many (and possibly Few to Many) proximity. As soon as Many to Many proximity is needed, even OSGi needs to choose more flexible design.
Follow
