Final interface
From APIDesign
(New page: Final interface is a pattern often used in vendor library style API design. TBD == Why it does not work? == (including the ones provided by the [[...) |
|||
| Line 1: | Line 1: | ||
| - | [[Final interface]] is a [[APIDesignPatterns|pattern]] often used in [[vendor library]] style [[API]] design. | + | [[Final interface]] is a [[APIDesignPatterns|pattern]] often used in [[vendor library]] style [[API]] design. It marks a [[Java]] interface in an [[API]] as ''final'' (either in [[Javadoc]] or elsewhere [[TBD]]) with the [[evolution]] plan to expand it incompatibly (from the point of implementers). The hope is that nobody except the implementers will every implement such interface. |
[[TBD]] | [[TBD]] | ||
| Line 5: | Line 5: | ||
== Why it does not work? == | == Why it does not work? == | ||
| - | + | DOM2 vs. DOM3 problems ([[TBD]]): (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]]). | |
== Why it works? == | == Why it works? == | ||
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. | ||
Revision as of 20:06, 8 May 2012
Final interface is a pattern often used in vendor library style API design. It marks a Java interface in an API as final (either in Javadoc or elsewhere TBD) with the evolution plan to expand it incompatibly (from the point of implementers). The hope is that nobody except the implementers will every implement such interface.
Why it does not work?
DOM2 vs. DOM3 problems (TBD): (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).
Why it works?
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.
Follow
