Final interface
From APIDesign
| Line 1: | Line 1: | ||
| - | [[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 | + | [[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 ever implement such interface. |
| - | + | ||
| - | + | ||
== Why it does not work? == | == Why it does not work? == | ||
| - | DOM2 vs. DOM3 problems | + | DOM2 vs. DOM3 problems are famous. The interfaces in [[DOM]] [[Java]] [[API]] were made [[Final interface]], but as the [[XML]] specification was still evolving it soon turned out the original interfaces are not satisfactory. The [[XML]] introduced namespaces and the [[Java]] [[DOM]] [[API]] needed to adopt to it. How can one do it with [[Final interface]]s? Well, you break backward compatibility for those who implement the interface - and there were many [[DOM]]2 parsers, as at certain point in time it was very popular to write own's [[XML]] parser. |
| + | |||
| + | If one worked only with the standard [[XML]] parser provided by the [[JDK]] itself together with the [[DOM]] [[API]] - everything worked fine. Of course, because of closest possible [[proximity]]! When you package your [[API] with (the only) implementation you don't have [[evolution]] and versioning problems - the [[proximity]] is so intimate, you don't have to think about versioning. | ||
| + | |||
| + | However most of the more complex [[Java]] applications were not satisfied with the default [[Java]] parser and needed to include different implementation. And hence the problems began - when one had implementation of [[DOM]]3 provided as a [[library]], but the [[DOM]]2 [[API]] provided by the [[JDK]], the linkage problems were endless. [[JDK]]'s distribution of [[DOM]]2 and parsers and applications relying on [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]) just created a unsolvable mess. | ||
== 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 07:36, 4 February 2015
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 ever implement such interface.
Why it does not work?
DOM2 vs. DOM3 problems are famous. The interfaces in DOM Java API were made Final interface, but as the XML specification was still evolving it soon turned out the original interfaces are not satisfactory. The XML introduced namespaces and the Java DOM API needed to adopt to it. How can one do it with Final interfaces? Well, you break backward compatibility for those who implement the interface - and there were many DOM2 parsers, as at certain point in time it was very popular to write own's XML parser.
If one worked only with the standard XML parser provided by the JDK itself together with the DOM API - everything worked fine. Of course, because of closest possible proximity! When you package your [[API] with (the only) implementation you don't have evolution and versioning problems - the proximity is so intimate, you don't have to think about versioning.
However most of the more complex Java applications were not satisfied with the default Java parser and needed to include different implementation. And hence the problems began - when one had implementation of DOM3 provided as a library, but the DOM2 API provided by the JDK, the linkage problems were endless. JDK's distribution of DOM2 and parsers and applications relying on DOM3 (which contains incompatible interfaces from provider point of view) just created a unsolvable mess.
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
