commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <>
Subject Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/
Date Sun, 04 Jan 2015 19:54:51 GMT
On 01/04/2015 08:27 PM, Benedikt Ritter wrote:
> 2015-01-04 19:56 GMT+01:00 Thomas Neidhart <>:
>> On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
>>> Hello Thomas,
>>> 2015-01-04 18:37 GMT+01:00 Thomas Neidhart <>:
>>>> On 01/04/2015 06:07 PM, wrote:
>>>>> Author: britter
>>>>> Date: Sun Jan  4 17:07:51 2015
>>>>> New Revision: 1649362
>>>>> URL:
>>>>> Log:
>>>>> ScanlineFilter really is an interface
>>>> there is usually a good reason to use an abstract class instead of an
>>>> interface in case the type is public.
>>> Yes, if the abstract class has some logic, which subclasses can leverage.
>>> This was not the case here.
>>>> This makes it possible to extend the interface even in minor interfaces.
>>> I don't understand what you mean. Can you give an example?
>> If you define a public interface that classes implement, you can not
>> change the interface during minor releases as this would potentially
>> break client code.
>> Thus there are cases where it is better to use an abstract base class
>> instead of an interface, especially if it is highly unlikely that
>> implementing classes will extend or implement other types.
>> In math we have several examples of this pattern, as it is much easier
>> to add new features considering the release policy in commons.
>> The pattern is more or less obsolete with java 8, as there you have the
>> possibility of default methods in interfaces, but as long as the minimum
>> required version is < java 8 you have to keep this in mind.
>>>> Maybe this is not necessary in this case, but should be kept in mind
>>>> when doing such changes.
>>> As long as an abstract class does not define logic, it doesn't make any
>>> sense to define it as a class, rather than as an interface. Using
>>> interfaces has an important advantage: you can only extend one class, but
>>> can implement more than one interface. So we should really only define
>>> abstract classes, if they have logic that justifies their existence.
>> well it depends on your use-case imho. From a clean object-oriented POV,
>> you are totally right, but you also have to consider the maintainability
>> aspect.
> I understand your point now. I've never thought about it this way and your
> right from an "evolving API" POV. Since we're currently designing the 1.0
> API, I'd like to leave it this way for now. Or would you rather like to see
> this commit reverted?

I think changes like these should at least be discussed on the ml so
that developers who worked on it for a longer time can comment. The 1.0
release is actually quite critical, as it will most likely remain the
stable branch for quite some time.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message