You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Mathieu Lirzin <ma...@nereide.fr> on 2019/10/19 16:32:10 UTC
Backward compatibility for Java interfaces
Hello,
In my recent work on refactoring ‘Container’ and ‘ContainerConfig’
classes (See trunk) I have chosen (without discussing on ML) to use
deprecation for stuff that were likely to be used by client code
implementing additional containers in their plugins.
However I have just discovered that in 2016 some refactoring work chose
a different approach by simply changing a method signature in the
‘ContainerConfig’ interface [1].
Having @Deprecated methods is a tradeoff that provides smoother
migration path for client code with the cost of cluttering our codebase
which make things harder to maintain.
So I would like to know what are the general expectations of people
developing OFBiz plugins in term of backward compatibility and what
people would recommend as a general guideline regarding “modifying
public Java interfaces”.
What do people think?
[1] https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Backward compatibility for Java interfaces
Posted by Taher Alkhateeb <sl...@gmail.com>.
I leave for the rest of the folks to pitch in. I would just say that I
think having a lot of care for the container-specific API in terms of
backwards compatibility is probably not very necessary. Very few
external components AFAIK rely on that part of the system, and this
whole piece of the architecture probably needs major re-hauling
anyway. The refactoring work that I did back in 2016 was only one step
that needs further improvement by others to keep improving the code
base.
On Sat, Oct 19, 2019 at 7:57 PM Mathieu Lirzin
<ma...@nereide.fr> wrote:
>
> Mathieu Lirzin <ma...@nereide.fr> writes:
>
> > However I have just discovered that in 2016 some refactoring work chose
> > a different approach by simply changing a method signature in the
> > ‘ContainerConfig’ interface [1].
> [...]
> > [1] https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56
>
> For the record I have discovered a similar approach in 2012 [2].
>
> [2] https://github.com/apache/ofbiz-framework/commit/c386b7fc9a8d61923efb9bbd2e472d1cac3d8a6f#diff-6a7b97cfa75c3d5f2ec74abbb2d42316L78-R78
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Backward compatibility for Java interfaces
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Mathieu Lirzin <ma...@nereide.fr> writes:
> However I have just discovered that in 2016 some refactoring work chose
> a different approach by simply changing a method signature in the
> ‘ContainerConfig’ interface [1].
[...]
> [1] https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56
For the record I have discovered a similar approach in 2012 [2].
[2] https://github.com/apache/ofbiz-framework/commit/c386b7fc9a8d61923efb9bbd2e472d1cac3d8a6f#diff-6a7b97cfa75c3d5f2ec74abbb2d42316L78-R78
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Backward compatibility for Java interfaces
Posted by Jacopo Cappellato <ja...@gmail.com>.
Hi Mathieu,
my suggestion, especially for these kinds of refactoring that affects the
inner parts of the framework is to focus more on clean and simple design
(and code) than over backward compatibility; a cleaner and smaller codebase
is more manageable and will be better maintained by the community.
Thanks for all your efforts!
Jacopo
On Sat, Oct 19, 2019 at 6:32 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> Hello,
>
> In my recent work on refactoring ‘Container’ and ‘ContainerConfig’
> classes (See trunk) I have chosen (without discussing on ML) to use
> deprecation for stuff that were likely to be used by client code
> implementing additional containers in their plugins.
>
> However I have just discovered that in 2016 some refactoring work chose
> a different approach by simply changing a method signature in the
> ‘ContainerConfig’ interface [1].
>
> Having @Deprecated methods is a tradeoff that provides smoother
> migration path for client code with the cost of cluttering our codebase
> which make things harder to maintain.
>
> So I would like to know what are the general expectations of people
> developing OFBiz plugins in term of backward compatibility and what
> people would recommend as a general guideline regarding “modifying
> public Java interfaces”.
>
> What do people think?
>
> [1]
> https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>