+1 to Javadoc. I am tempted to -1 final, but I never say -1. Every framework that has final, and doesn't do quite what is required is a complete nightmare to use. I remember Hibernate in the early days when everything was final, and nothing worked properly. It was impossible to fix except by forking the entire codebase. The response from the Hibernate team was, "we know better than you", which in most cases was wrong because they didn't know what the "you" needed to do.
We don't know how all people might want to use Sling. They might want/need to extend a core service in order to cover their use cases. If we make that core service final, they have no option but to cut and paste the code. When they come to upgrade, its too hard and they fork, effectively leaving the community. Finally, ;) , last time I read the java memory management docs and hotspot description, IIRC, final can prevent hotspot optimising the code, so some versions strip it or ignore it. I would have to find the detail to be certain of that. I don't really have a problem with final as a keyword to aid the compiler, but as an architectural feature it removes freedom of expression, and as a runtime feature its arrogant. Just my 2c. Ian On 5 August 2013 20:58, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi > > Am 05.08.2013 um 19:48 schrieb Justin Edelson: > >> Hi Felix, >> +1 to all of this. >> >> Out of curiosity, would adding the final keyword require a major version >> bump? It isn't backwards compatible, but is perhaps an interesting grey >> area. > > Yes, technically, this is binary incompatible because existing extensions > will fail to load. > > An option would be to omit the final qualifier but add JavaDoc indicating > extension is not intended. > > Regards > Felix > >> >> Justin >> >> On Mon, Aug 5, 2013 at 11:04 AM, Felix Meschberger <fmesc...@adobe.com>wrote: >> >>> Hi all >>> >>> While working on SLING-2944 [1] it occurred to me that we do not currently >>> take good care to differentiate between interfaces to be implemented by a >>> single bundle (such as SlingHttpServletRequest) and interfaces which may be >>> implemented by multiple bundles to extend some functionality (such as >>> ResourceProvider). >>> >>> Also, we have a number of constant, helper, and utility type classes in >>> the Sling API, which we should not make available to extensibility. >>> >>> I have created SLING-2993 [2] and provided a patch to the Sling API such >>> that: >>> >>> * All classes intended for extension remain unchanged >>> * All classes not intended for extension are marked final >>> * All interfaces intended to be implemented by multiple bundles >>> (providers) are marked @ConsumerType >>> * All interfaces intended to be implemented by a single bundle are marked >>> as @ProviderType >>> >>> This change also requires to update the Maven Bundle Plugin version in the >>> Sling parent POM to 2.4.0. >>> >>> This change would prevent us from collateral damage such in the context of >>> SLING-2944 where the Servlet Resolver, Filesystem Resource Provider, and >>> Bundle Resource Provider bundles have to be updated just because the >>> ResourceResolverFactory API has been extended. >>> >>> WDYT ? >>> >>> Regards >>> Felix >>> >>> [1] https://issues.apache.org/jira/browse/SLING-2944 >>> [2] https://issues.apache.org/jira/browse/SLING-2993 >