It may seem most of this discussion is obsolete with [[JDK]]8 [[DefaultMethods]]. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then mostly compatible extension (however only mostly, read [[BinaryCompatibleDefaultMethods]] for more horror stories about [[DefaultMethods]] - there is no free lunch!). Reasonable [[API]] writers then provide the default bodies for newly added methods and mitigate most of the [[DOM]]2 vs. [[DOM]]3 problems by that.

It may seem most of this discussion is obsolete with [[JDK]]8 [[DefaultMethods]]. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then mostly compatible extension (however only mostly, read [[BinaryCompatibleDefaultMethods]] for more horror stories about [[DefaultMethods]] - there is no free lunch!). Reasonable [[API]] writers then provide the default bodies for newly added methods and mitigate most of the [[DOM]]2 vs. [[DOM]]3 problems by that.

It is however interesting to analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language (correct as [[DefaultMethods]] decrease [[clarity]] of the [[provider]] interface).

It is however interesting to analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language (correct as [[DefaultMethods]] decrease [[clarity]] of the [[ProviderAPI]] interface).

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

== [[JDK]]: Scratching Own Itch! ==

== [[JDK]]: Scratching Own Itch! ==

Of course most of this discussion is becoming obsolete with [[JDK]]8 extender methods. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then source and binary compatible extension. Reasonable [[API]] writers will then provide the default bodies for newly added methods and mitigate the [[DOM]]2 vs. [[DOM]]3 problems by that.

It may seem most of this discussion is obsolete with [[JDK]]8 [[DefaultMethods]]. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then mostly compatible extension (however only mostly, read [[BinaryCompatibleDefaultMethods]] for more horror stories about [[DefaultMethods]] - there is no free lunch!). Reasonable [[API]] writers then provide the default bodies for newly added methods and mitigate most of the [[DOM]]2 vs. [[DOM]]3 problems by that.

It is however interesting to analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language.

It is however interesting to analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language (correct as [[DefaultMethods]] decrease [[clarity]] of the [[provider]] interface).

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

All that is needed is to motivate owner of [[HotSpot]] to implement some small enhancement. That however requires the owner to feel the pain - e.g. simulate common problem in context of [[JDK]] - that is however tough - [[JDK]] is specific isolated project and problems they face are often too different from real world ones. But when a rare situation happens (e.g. [[JDK]] feels the same problem as rest of the world), ''scratching own itch'' can really move things forward!

All that is needed is to motivate owner of [[HotSpot]] to implement some small enhancement. That however requires the owner to feel the pain - e.g. simulate common problem in context of [[JDK]] - that is however tough - [[JDK]] is specific isolated project and problems they face are often too different from real world ones. But when a rare situation happens (e.g. [[JDK]] feels the same problem as the rest of the world), ''scratching own itch'' can really move things forward!

== Enforcing [[final interface]] During Compilation ==

== Enforcing [[final interface]] During Compilation ==

== Enforcing [[final interface]] During Compilation ==

== Enforcing [[final interface]] During Compilation ==

There is a way to turn the ''don't implement me, please'' [[Javadoc]] warning into something real, that will open eyes of everyone who tries to implement a [[final interface]]. There is a way to fail one's build in case of violation of the advice! The check can be done with a simple [[AnnotationProcessor]]. When you have your [[final interface]]:

There is a way to turn the ''don't implement me, please'' [[Javadoc]] warning into something real, something that will open eyes of everyone who tries to implement a [[final interface]]. There is a way to fail one's build in case of violation of the advice! The check can be done with a simple [[AnnotationProcessor]]. When you have your [[final interface]]:

<source lang="java">

<source lang="java">

</source>

</source>

A compile check of this kind makes the [[API Design]]er in me way more happier! Users of your [[API]] are may be [[clueless]] (as I always claim) and may not bother reading documentation, but none of them can ignore failing build!

A compile check of this kind makes the [[API Design]]er in me way more happier! Users of your [[API]] may be [[clueless]] (as I always claim) and may not bother reading documentation, but none of them can ignore failing build!

A [[final interface]] accompanied by an [[AnnotationProcessor]] is finally real [[:Category:APIDesignPatterns|API Design Pattern]]!

A [[final interface]] accompanied by an [[AnnotationProcessor]] is finally real [[:Category:APIDesignPatterns|API Design Pattern]]!

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Evolution]]

TypeElement te = (TypeElement) e;

TypeElement te = (TypeElement) e;

/* exception for the only known implementation:

/* exception for the only known implementation:

if ("org.apidesign.demo.finalinterface.AllowedImplementationTest".equals(te.getQualifiedName().toString())) continue;

if ("org.apidesign.demo.finalinterface.AllowedImplementationTest".equals(

te.getQualifiedName().toString())

) continue;

*/

*/

for (TypeMirror m : te.getInterfaces()) {

for (TypeMirror m : te.getInterfaces()) {

if (e instanceof TypeElement) {

if (e instanceof TypeElement) {

TypeElement te = (TypeElement) e;

TypeElement te = (TypeElement) e;

if ("org.apidesign.demo.finalinterface.AllowedImplementationTest".equals(te.getQualifiedName().toString())) {

continue;

if ("org.apidesign.demo.finalinterface.AllowedImplementationTest".equals(te.getQualifiedName().toString())) continue;

for (TypeMirror m : te.getInterfaces()) {

for (TypeMirror m : te.getInterfaces()) {

if (FinalInterface.class.getName().equals(m.toString())) {

if (FinalInterface.class.getName().equals(m.toString())) {

processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR, "Cannot implement FinalInterface", e);

processingEnv.getMessager().printMessage(

Diagnostic.Kind.ERROR, "Cannot implement FinalInterface", e

);

}

}

}

}

</source>

</source>

A compile check of this kind make the [[API Design]]er in me way more happier! Users of your [[API]] are going to be [[clueless]] (as I always claim) and will not bother reading documentation, but none of them ignore failing build!

A compile check of this kind makes the [[API Design]]er in me way more happier! Users of your [[API]] are may be [[clueless]] (as I always claim) and may not bother reading documentation, but none of them can ignore failing build!

A [[final interface]] accompanied by an [[AnnotationProcessor]] is finally real [[:Category:APIDesignPatterns|API Design Pattern]]!

A [[final interface]] accompanied by an [[AnnotationProcessor]] is finally real [[:Category:APIDesignPatterns|API Design Pattern]]!

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Evolution]]

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

All that is needed is to motivate owner of [[HotSpot]] to implement some small enhancement. That however requires the owner to feel the pain - e.g. simulate common problem in context of [[JDK]] - that is however tough - [[JDK]] is specific isolated project and problems they face are often too different from real world ones. But when a rare situation happens (e.g. [[JDK]] feels the problem as rest of the world), ''scratching own itch'' can really move things forward!

All that is needed is to motivate owner of [[HotSpot]] to implement some small enhancement. That however requires the owner to feel the pain - e.g. simulate common problem in context of [[JDK]] - that is however tough - [[JDK]] is specific isolated project and problems they face are often too different from real world ones. But when a rare situation happens (e.g. [[JDK]] feels the same problem as rest of the world), ''scratching own itch'' can really move things forward!

== Enforcing [[final interface]] During Compilation ==

== Enforcing [[final interface]] During Compilation ==

Of course most of this discussion is becoming obsolete with [[JDK]]8 extender methods. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then source and binary compatible extension. Reasonable [[API]] writers will then provide the default bodies for newly added methods and mitigate the [[DOM]]2 vs. [[DOM]]3 problems by that.

Of course most of this discussion is becoming obsolete with [[JDK]]8 extender methods. With [[JDK]]8 you can add new methods with ''default implementations'' into existing interfaces - which is then source and binary compatible extension. Reasonable [[API]] writers will then provide the default bodies for newly added methods and mitigate the [[DOM]]2 vs. [[DOM]]3 problems by that.

It is however interesting the analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language.

It is however interesting to analyze the reasons why ''extender methods'' were introduced. Of course, people we crying for them for ages, but the members of [[JDK]] team were refusing all such efforts. Why? To keep the purity of the language.

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

However when they finally felt all the pain - e.g. when the {{JDK|java/util|Collection}} and etc. interfaces were found insufficient, they immediately changed their mind. And of course, because they control the [[VM]], they could do (unlike us, regular outsider beings) miracles. It is way easier to resolve [[backward compatibility]] issues if you control the way linkage is done!

The above problems can be slightly 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. If the [[RangeDependencies|version range]] used by clients is wider than [[RangeDependencies|version range]] used by implementations proper versioning is possible and the [[OSGi]] container can select the right modules to compose a working system. More about this in the [[proximity]] essay. However it needs to be stated that this works only in [[vendor library|One to Many]] and in [[Semantic versioning|Few to Many]] mode - e.g. when there is a single provider (or few of them) of the [[DOM]] parser and many users of the [[DOM]] parsing API. Then one can use [[OSGi]] [[RangeDependencies]] to make sure the implementation has closer [[proximity]] than users of the [[DOM]] [[API]].

The above problems can be slightly 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. If the [[RangeDependencies|version range]] used by clients is wider than [[RangeDependencies|version range]] used by implementations proper versioning is possible and the [[OSGi]] container can select the right modules to compose a working system. More about this in the [[proximity]] essay. However it needs to be stated that this works only in [[vendor library|One to Many]] and in [[Semantic versioning|Few to Many]] mode - e.g. when there is a single provider (or few of them) of the [[DOM]] parser and many users of the [[DOM]] parsing API. Then one can use [[OSGi]] [[RangeDependencies]] to make sure the implementation has closer [[proximity]] than users of the [[DOM]] [[API]].

Once you end up with multiple [[DOM]] parser implementations in your application (like [[NetBeans]] - a large and [[modular]] application - did) - e.g. you enter [[modular library|Many to Many]] relationship, no close [[proximity]] is going to save you. The only saving point is to adhere to best [[API Design]] practice and separate [[ClientAPI]] from [[ProviderAPI]]s. As such [[I]] am going to include [[final interface]] in [[API Design]] anti patterns although [[I]] am sure [[OSGi]] friends will never try to understand the [[ClarityOfTypes|better alternative]].

Once you end up with multiple [[DOM]] parser implementations in your application (like [[NetBeans]] - a large and [[modular]] application - did) - e.g. you enter [[modular library|Many to Many]] relationship, no close [[proximity]] is going to save you. The only saving point is to adhere to best [[API Design]] practice and separate [[ClientAPI]] from [[ProviderAPI]]s. As such [[I]] am going to include [[final interface]] in [[API Design]] anti patterns although [[I]] am sure [[OSGi]] friends will never try to understand such [[ClarityOfTypes|better alternative]] and stick to their [[proximity|own old guns]].

== [[JDK]]: Scratching Own Itch! ==

== [[JDK]]: Scratching Own Itch! ==