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]].

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]].

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.

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]] 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]].

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]].

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.

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]] 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|different design]].

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]].

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 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.

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]]. 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]].

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|different design]].

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 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.

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.

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]].

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]].

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 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.

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.

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.

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]].

 

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

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: [[TBD]]

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. One could almost say that [[OSGi]] has been designed to make [[final interface]] a [[good]] design pattern.

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.

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.

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

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 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 {{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]] usually hidden beneath SAX of [[DOM]] [[API]]s.

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: [[TBD]]

 

 

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.

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.

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

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 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.

{{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]]).

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]] usually hidden beneath SAX of [[DOM]] [[API]]s.

 

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]]).

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.

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.

Another typical kind of [[library]] is based on standardized specification, but it expects multiple vendors to provide different implementation. On the other hand, it is almost always expected that there will be just a single such implementation in a running system.

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.

{{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]]).

{{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]]).