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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
