Final interface

From APIDesign

Revision as of 07:36, 4 February 2015 by JaroslavTulach (Talk | contribs)
Jump to: navigation, search

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.

Personal tools
buy