http://wiki.apidesign.org/index.php?action=history&feed=atom&title=Vendor_library 2026-05-01T16:30:17Z Revision history for this page on the wiki MediaWiki 1.12.0rc1 http://wiki.apidesign.org/index.php?title=Vendor_library&diff=8173&oldid=prev 2015-02-04T07:13:11Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 07:13, 4 February 2015</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 6:</td> <td colspan="2" class="diff-lineno">Line 6:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]].</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"></ins></div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Evolution]]</ins></div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=6129&oldid=prev 2012-09-27T07:35:35Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 07:35, 27 September 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>After visiting [[OSGiCon]] in 2012 and having few chats with folks like <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>Peter Kriens<ins style="color: red; font-weight: bold; text-decoration: none;">]] </ins>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]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5752&oldid=prev 2012-05-12T19:17:08Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:17, 12 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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|<del style="color: red; font-weight: bold; text-decoration: none;">different </del>design]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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|<ins style="color: red; font-weight: bold; text-decoration: none;">more flexible </ins>design]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5751&oldid=prev 2012-05-12T19:16:32Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:16, 12 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 <del style="color: red; font-weight: bold; text-decoration: none;">finding </del>[[Modular library|better alternative]]. [[OSGi|Other people]] however had <del style="color: red; font-weight: bold; text-decoration: none;">other </del>opinion and invested a <del style="color: red; font-weight: bold; text-decoration: none;">lot </del>of energy to find out under which conditions [[final interface]] is acceptable pattern.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 <ins style="color: red; font-weight: bold; text-decoration: none;">inventing a </ins>[[Modular library|better alternative]]. [[OSGi|Other people]] however had <ins style="color: red; font-weight: bold; text-decoration: none;">different </ins>opinion and invested a <ins style="color: red; font-weight: bold; text-decoration: none;">bunch </ins>of energy to find out under which conditions [[final interface]] is <ins style="color: red; font-weight: bold; text-decoration: none;">an </ins>acceptable pattern.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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]]. <del style="color: red; font-weight: bold; text-decoration: none;">Know </del>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 <del style="color: red; font-weight: bold; text-decoration: none;">is </del>only <del style="color: red; font-weight: bold; text-decoration: none;">good at most for 1-N </del>[[proximity]]. As soon as [[Modular library|<del style="color: red; font-weight: bold; text-decoration: none;">M-N</del>]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|different design]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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]] <ins style="color: red; font-weight: bold; text-decoration: none;">now</ins>. 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 <ins style="color: red; font-weight: bold; text-decoration: none;">works well </ins>only <ins style="color: red; font-weight: bold; text-decoration: none;">with [[vendor library|One to Many]] (and possibly [[Semantic versioning|Few to Many]]) </ins>[[proximity]]. As soon as [[Modular library|<ins style="color: red; font-weight: bold; text-decoration: none;">Many to Many</ins>]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|different design]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5723&oldid=prev 2012-05-08T20:42:16Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 20:42, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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<del style="color: red; font-weight: bold; text-decoration: none;">]</del>]]) and we (me and others in the [[NetBeans]] project) invested a lot in finding [[Modular library|better alternative]]. [[OSGi|Other people]] however had other opinion and invested a lot of energy to find out under which conditions [[final interface]] is acceptable pattern.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 finding [[Modular library|better alternative]]. [[OSGi|Other people]] however had other opinion and invested a lot of energy to find out under which conditions [[final interface]] is acceptable pattern.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. Know 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 is only good at most for 1-N [[proximity]]. As soon as [[Modular library|M-N]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|different design]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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]]. Know 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 is only good at most for 1-N [[proximity]]. As soon as [[Modular library|M-N]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|different design]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5722&oldid=prev 2012-05-08T20:38:40Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 20:38, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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 finding [[Modular library|better alternative]]. [[OSGi|Other people]] however had other opinion and invested a lot of energy to find out under which conditions [[final interface]] is acceptable <del style="color: red; font-weight: bold; text-decoration: none;">pattern. One could almost say that [[OSGi]] has been designed to make [[final interface]] a [[good]] design </del>pattern.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 finding [[Modular library|better alternative]]. [[OSGi|Other people]] however had other opinion and invested a lot of energy to find out under which conditions [[final interface]] is acceptable pattern.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>After visiting [[OSGiCon]] I can see the value of <del style="color: red; font-weight: bold; text-decoration: none;">this category, but yes, I have to admit </del>I <del style="color: red; font-weight: bold; text-decoration: none;">feel uneasy</del>. <del style="color: red; font-weight: bold; text-decoration: none;">But </del>that <del style="color: red; font-weight: bold; text-decoration: none;">is OK, people are supposed </del>to <del style="color: red; font-weight: bold; text-decoration: none;">feel uneasy when they have to accept new ideas</del>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>After visiting [[OSGiCon]] <ins style="color: red; font-weight: bold; text-decoration: none;">in 2012 and having few chats with folks like Peter Kriens </ins>I can <ins style="color: red; font-weight: bold; text-decoration: none;">confirm I </ins>see the value of <ins style="color: red; font-weight: bold; text-decoration: none;">[[vendor library]] [[proximity]]. Know </ins>I <ins style="color: red; font-weight: bold; text-decoration: none;">can understand [[OSGi]] better</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">I could almost say </ins>that <ins style="color: red; font-weight: bold; text-decoration: none;">[[OSGi]] has been designed </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">make [[final interface]] a [[good]] design pattern</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">However one has to keep in mind that this </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">API</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">design style is only good at most for </ins>1-N <ins style="color: red; font-weight: bold; text-decoration: none;">[[proximity]]. As soon as [[Modular library|</ins>M<ins style="color: red; font-weight: bold; text-decoration: none;">-N]] [[proximity]] is needed, even [[OSGi]] needs to choose [[Modular library|different design]]</ins>.</div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>&#160;</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">Talk about: </del>[[<del style="color: red; font-weight: bold; text-decoration: none;">ModularLibrary</del>]] <del style="color: red; font-weight: bold; text-decoration: none;">with </del>1-N <del style="color: red; font-weight: bold; text-decoration: none;">and N-</del>M <del style="color: red; font-weight: bold; text-decoration: none;">proximities</del>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5721&oldid=prev 2012-05-08T20:20:53Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 20:20, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The close [[proximity]] of the vendor of the implementation and the [[API]] (as they are packaged together) leads to so called [[<del style="color: red; font-weight: bold; text-decoration: none;">Final </del>interface]] design<del style="color: red; font-weight: bold; text-decoration: none;">: </del>[[<del style="color: red; font-weight: bold; text-decoration: none;">TBD</del>]]</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The close [[proximity]] of the vendor of the implementation and the [[API]] (as they are packaged together) leads to so called [[<ins style="color: red; font-weight: bold; text-decoration: none;">final </ins>interface]] design<ins style="color: red; font-weight: bold; text-decoration: none;">. This kind of design caused heavy nightmares as soon as the </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">XML</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">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 finding [[Modular library|better alternative]]. [[OSGi|Other people]] however had other opinion and invested a lot of energy to find out under which conditions [[final interface]] is acceptable pattern. One could almost say that [[OSGi]] has been designed to make [[final interface]] a [[good]] design pattern.</ins></div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Talk about: [[ModularLibrary]] with 1-N and N-M proximities.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Talk about: [[ModularLibrary]] with 1-N and N-M proximities.</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5718&oldid=prev 2012-05-08T19:56:26Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:56, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>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]] <del style="color: red; font-weight: bold; text-decoration: none;">usually </del>hidden <del style="color: red; font-weight: bold; text-decoration: none;">beneath SAX </del>of [[DOM]] [[API]]<del style="color: red; font-weight: bold; text-decoration: none;">s</del>. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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]] <ins style="color: red; font-weight: bold; text-decoration: none;">parser. Often the implementation was </ins>hidden <ins style="color: red; font-weight: bold; text-decoration: none;">behind the facade </ins>of <ins style="color: red; font-weight: bold; text-decoration: none;">SAX or </ins>[[DOM]] [[API]]<ins style="color: red; font-weight: bold; text-decoration: none;">. Such parsers also package their copy of the [[API]] (as providers of [[vendor library]] are supposed to do)</ins>.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">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 [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).</del></div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The close [[proximity]] of the vendor of the implementation <ins style="color: red; font-weight: bold; text-decoration: none;">and </ins>the [[API]] (as they are packaged together) leads to so called [[Final interface]] design: [[TBD]]</div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>&#160;</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">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 [[OSGi]]4.3 capabilities this seems very easy to specify and achieve. </del></div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>&#160;</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The close [[proximity]] of the vendor of the implementation <del style="color: red; font-weight: bold; text-decoration: none;">with </del>the [[API]] (as they are packaged together) leads to so called [[Final interface]] design: [[TBD]]</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div></div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Talk about: [[ModularLibrary]] with 1-N and N-M proximities.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Talk about: [[ModularLibrary]] with 1-N and N-M proximities.</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5717&oldid=prev 2012-05-08T19:41:23Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:41, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>{{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}} <del style="color: red; font-weight: bold; text-decoration: none;">are </del>one of the most well-known examples of a [[vendor library]]. Especially in beginning of 21st century<del style="color: red; font-weight: bold; text-decoration: none;">, people were trying to provide </del>many <del style="color: red; font-weight: bold; text-decoration: none;">different </del>implementation of <del style="color: red; font-weight: bold; text-decoration: none;">''SAX'' and </del>[[<del style="color: red; font-weight: bold; text-decoration: none;">DOM</del>]] <del style="color: red; font-weight: bold; text-decoration: none;">parsers </del>hidden beneath <del style="color: red; font-weight: bold; text-decoration: none;">the common </del>[[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 [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">The [[API]] for [[XML]] processing in [[Java]] (with entry points in </ins>{{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}}<ins style="color: red; font-weight: bold; text-decoration: none;">) is </ins>one of the most well-known examples of a [[vendor library]]. Especially in <ins style="color: red; font-weight: bold; text-decoration: none;">the </ins>beginning of 21st century <ins style="color: red; font-weight: bold; text-decoration: none;">it was a common hobby among </ins>many <ins style="color: red; font-weight: bold; text-decoration: none;">programmers to write own </ins>implementation of <ins style="color: red; font-weight: bold; text-decoration: none;">an </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">XML</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">usually </ins>hidden beneath <ins style="color: red; font-weight: bold; text-decoration: none;">SAX of [[DOM]] </ins>[[API]]<ins style="color: red; font-weight: bold; text-decoration: none;">s</ins>. </div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>&#160;</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>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 [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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 [[OSGi]]4.3 capabilities this seems very easy to specify and achieve. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>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 [[OSGi]]4.3 capabilities this seems very easy to specify and achieve. </div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Vendor_library&diff=5716&oldid=prev 2012-05-08T19:33:36Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:33, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div><del style="color: red; font-weight: bold; text-decoration: none;">Another typical </del>kind of [[library]] is based on standardized specification<del style="color: red; font-weight: bold; text-decoration: none;">, but it expects </del>multiple vendors <del style="color: red; font-weight: bold; text-decoration: none;">to provide </del>different implementation. On the other hand, it is almost always <del style="color: red; font-weight: bold; text-decoration: none;">expected </del>that there <del style="color: red; font-weight: bold; text-decoration: none;">will be just </del>a single <del style="color: red; font-weight: bold; text-decoration: none;">such </del>implementation in a running system. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">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 </ins>kind of [[library]] is based on standardized specification<ins style="color: red; font-weight: bold; text-decoration: none;">. Usually </ins>multiple vendors <ins style="color: red; font-weight: bold; text-decoration: none;">with similar functionality sit down and agree on a specification. Each of them then provides their own </ins>different implementation<ins style="color: red; font-weight: bold; text-decoration: none;">. This was the case for [[EJB]], [[JAX-RS]], [[OSGi]] and possibly many others</ins>. On the other hand, it is almost always <ins style="color: red; font-weight: bold; text-decoration: none;">the case </ins>that there <ins style="color: red; font-weight: bold; text-decoration: none;">is only </ins>a single implementation <ins style="color: red; font-weight: bold; text-decoration: none;">of such specification </ins>in a running system. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>{{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|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 [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>{{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|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 [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).</div></td></tr> </table>

JaroslavTulach