Re: [DISCUSS] Consider implementors of Sling API
Hi Am 06.08.2013 um 08:03 schrieb Carsten Ziegeler: In general I'm fine with this, however as Justin noted adding final to some of the classes might break clients of Sling. Marking an interface as ConsumerType means also we shouldn't change it, right? (i'm fine with that, just clarifying) Yes. The implication of @ConsumerType is that any change requires a major version increment in the package export. This is a burden to us API designers but helps consumers ;-) Regards Felix Carsten 2013/8/5 Felix Meschberger fmesc...@adobe.com 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 -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Consider implementors of Sling API
Hi On final and my proposal: The problem is extensibility, planning for extensibility and inadvertent extensibility. My proposal for final (if it would not break backwards compatibility which is reason enough to not do it) would not hamper any consumers because it would be for classes exposing constants or utility methods. Everything is static in there. So no extension will ever be able to overwrite and be sure it is being used anyways. So no harm done in that respect. Other than that, final is a keyword like abstract and interface which must consciously be used or not used. Fortunately in the OSGi world we have another means of preventing inadvertent and unplanned extensions by hiding complete packages. So, given that we consciously expose classes and interface we deem suitable for consumption and extension we solve a lot of the design issues. There might still be cases for marking something final: utility classes and constant classes. Regards Felix Am 06.08.2013 um 08:14 schrieb Ian Boston: +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.comwrote: 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
Re: [DISCUSS] Consider implementors of Sling API
Hi, On Thu, Aug 8, 2013 at 8:18 AM, Felix Meschberger fmesc...@adobe.com wrote: My proposal for final ...would be for classes exposing constants or utility methods. Everything is static in there... So, do I understand correctly that you only intend to make a class final if a class only has static constants and methods? That would work for me, and like others I'm not for making everything final, as you say we need to be more subtle than that. -Bertrand
Re: [DISCUSS] Consider implementors of Sling API
Hi Am 08.08.2013 um 09:36 schrieb Bertrand Delacretaz: Hi, On Thu, Aug 8, 2013 at 8:18 AM, Felix Meschberger fmesc...@adobe.com wrote: My proposal for final ...would be for classes exposing constants or utility methods. Everything is static in there... So, do I understand correctly that you only intend to make a class final if a class only has static constants and methods? No, not in general. There may be classes which make sense to make final. But the current proposal for the Sling API was just about classes, which have static methods and constants. That would work for me, and like others I'm not for making everything final, as you say we need to be more subtle than that. Exactly. Regards Felix -Bertrand
Re: [DISCUSS] Consider implementors of Sling API
In general I'm fine with this, however as Justin noted adding final to some of the classes might break clients of Sling. Marking an interface as ConsumerType means also we shouldn't change it, right? (i'm fine with that, just clarifying) Carsten 2013/8/5 Felix Meschberger fmesc...@adobe.com 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 -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Consider implementors of Sling API
+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.comwrote: 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
Re: [DISCUSS] Consider implementors of Sling API
On 6 August 2013 07:14, Ian Boston i...@tfd.co.uk wrote: 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. [1] Page 25 indicates the problems associated with using final on fields, not least that if it is relied upon to isolate a class during construction that can't be guaranteed. Also, don't forget, serialisation and reflection make it possible to bypass final. Also [2] which is a little old has some views on the subject as does [3], not all of the pointers are relevant to final classes and final is not all bad but as [2] says its overused and sometimes in the wrong way which can lead to problems downstream. Part of Java's speed under load is the ability to dynamically inline methods. To do that methods must be small. Putting final keywords in on methods and classes blocks extension (fields are possibly ok) which results in more, cooler spots from a hotspot point of view, resulting less efficient runtime optimisation, and relying entirely on the programmer to know everything about the runtime to deliver better than interpreted speed. But I am +1 on documentation and any other methods we can find to indicate our intention. Ian 1 http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf 2 http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html 3 http://www.oracle.com/technetwork/java/whitepaper-135217.html#impact
[DISCUSS] Consider implementors of Sling API
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
RE: [DISCUSS] Consider implementors of Sling API
+1 Regards, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 05 August 2013 20:35 To: dev@sling.apache.org Subject: [DISCUSS] Consider implementors of Sling API 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
Re: [DISCUSS] Consider implementors of Sling API
+1 On Mon, Aug 5, 2013 at 11:18 AM, Amit.. Gupta. amitg...@adobe.com wrote: +1 Regards, Amit -Original Message- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 05 August 2013 20:35 To: dev@sling.apache.org Subject: [DISCUSS] Consider implementors of Sling API 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
Re: [DISCUSS] Consider implementors of Sling API
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. Justin On Mon, Aug 5, 2013 at 11:04 AM, Felix Meschberger fmesc...@adobe.comwrote: 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
Re: [DISCUSS] Consider implementors of Sling API
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.comwrote: 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
