You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/08/05 17:04:30 UTC

[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

Posted by Daniel Klco <dk...@apache.org>.
+1


On Mon, Aug 5, 2013 at 11:18 AM, Amit.. Gupta. <am...@adobe.com> wrote:

> +1
>
> Regards,
> Amit
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@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

Posted by "Amit.. Gupta." <am...@adobe.com>.
+1

Regards,
Amit

-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@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

Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@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 <fmeschbe@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
> cziegeler@apache.org

Re: [DISCUSS] Consider implementors of Sling API

Posted by Carsten Ziegeler <cz...@apache.org>.
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 <fm...@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 <fmeschbe@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
cziegeler@apache.org

Re: [DISCUSS] Consider implementors of Sling API

Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 August 2013 07:14, Ian Boston <ie...@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

Re: [DISCUSS] Consider implementors of Sling API

Posted by Felix Meschberger <fm...@adobe.com>.
Hi

Am 08.08.2013 um 09:36 schrieb Bertrand Delacretaz:

> Hi,
> 
> On Thu, Aug 8, 2013 at 8:18 AM, Felix Meschberger <fm...@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

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Thu, Aug 8, 2013 at 8:18 AM, Felix Meschberger <fm...@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

Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@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 <fm...@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
>>

Re: [DISCUSS] Consider implementors of Sling API

Posted by Ian Boston <ie...@tfd.co.uk>.
+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 <fm...@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 <fm...@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
>

Re: [DISCUSS] Consider implementors of Sling API

Posted by Felix Meschberger <fm...@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 <fm...@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

Re: [DISCUSS] Consider implementors of Sling API

Posted by Justin Edelson <ju...@justinedelson.com>.
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 <fm...@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