Hi, related to my earlier mail on deprecations there's another thought I'd like to discuss. When evolving an SPI (typically *implemented* by clients), other restrictions apply than when evolving an API (typically *used* by clients). More specifically, it's no problem to add new methods to an API interface (existing clients continue to function without changes), while that's not true for SPI interfaces (existing implementations break). AFAIK there are basically two approaches for handling the evolvement of SPIs. One is to use use abstract classes instead of interfaces for SPI types. This allows to add new methods in future versions as long as a sensible default implementation in the abstract class can be provided. Implementation classes can override that default implementation if they want to. The other approach is to create a new interface extending the existing one in order to add new methods: public interface Foo { void bar(); } public interface Foo2 extends Foo { void baz(); } Clients implement the latest version they are aware of and want to support. For our own code this means that we have to perform some instanceof calls to determine the version of the passed SPI types. My question now is, whether you got any recommendations for this. Do you have any experience with either approach in other Hibernate projects? Thanks, --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Apr 2, 2012, at 11:16 AM, Emmanuel Bernard wrote: > What's your definition of an SPI, in the team we have slightly different ones. > > In Hibernate search an SPI is targeted at frameworks or hyper advanced user who are willing to integrate or enhance Hibernate Search. Otherwise, they are considered APIs - which includes interfaces you might need to implement like FieldBridge. Hibernate ORM has a different semantic where an API is what the application directly code on. The HV interpretation of SPI is the same view as in ORM. Imo It makes for a simpler, easier to understand cut between API and SPI. > For your second question, I have used the idea of an interface combined with an abstract class with success. The interface used by the consumers and the abstract class extended by implementors. I also think that an abstract class can be beneficial. However, I would not generalize this approach. In the case of the HV interfaces in question we have very simple interfaces (single method ones) with a very low likelihood that they will change. I don't think that the abstract base class is needed in this case, especially since it forces you to use inheritance.

What's your definition of an SPI

That's the proposal I have pushed to the common guidelines at JBoss.

On 2 avr. 2012, at 11:44, Hardy Ferentschik wrote: >> >> What's your definition of an SPI, in the team we have slightly different ones. >> >> In Hibernate search an SPI is targeted at frameworks or hyper advanced user who are willing to integrate or enhance Hibernate Search. Otherwise, they are considered APIs - which includes interfaces you might need to implement like FieldBridge. Hibernate ORM has a different semantic where an API is what the application directly code on. > > The HV interpretation of SPI is the same view as in ORM. Imo It makes for a simpler, easier to understand cut between API and SPI. You guys think too much of your own comfort and less of the user's ;P _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi, > What's your definition of an SPI I think an SPI is something which the user implements (as you say typically advanced users which need to plug-in custom functionality into the framework) opposed to an API, which is something which a user just uses/invokes. > That's the proposal I have pushed to the common guidelines at JBoss. Do you have a link to these guidelines? I think I like the combined interface/abstract implementation approach. --Gunnar 2012/4/2 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > > On 2 avr. 2012, at 11:44, Hardy Ferentschik wrote: > >>> >>> What's your definition of an SPI, in the team we have slightly different ones. >>> >>> In Hibernate search an SPI is targeted at frameworks or hyper advanced user who are willing to integrate or enhance Hibernate Search. Otherwise, they are considered APIs - which includes interfaces you might need to implement like FieldBridge. Hibernate ORM has a different semantic where an API is what the application directly code on. >> >> The HV interpretation of SPI is the same view as in ORM. Imo It makes for a simpler, easier to understand cut between API and SPI. > > You guys think too much of your own comfort and less of the user's ;P > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev