AbstractList etc. functionality as interfaces with default methods? (original) (raw)
Attila Szegedi attila.szegedi at oracle.com
Fri May 8 09:41:56 UTC 2015
- Previous message: RFR [9] RandomFactory should be in the jdk.testlibrary package
- Next message: AbstractList etc. functionality as interfaces with default methods?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
So I’m in a position where I’d need to have a class implement List, but it already extends something else, so I can’t have it extend AbstractList, which leaves me with a lot of boilerplate methods to implement.
Would it seem like a good idea to reimagine AbstractList and friends as interfaces with default methods?
Of course, I know that technically for backwards compatibility we can’t really do this, but what we could do is:
public interface DefaultList extends List { … add all methods from AbstractList here as default methods … }
public abstract class AbstractList implements DefaultList { }
(I’ll hand-wave the issue of “protected int modCount” issue for now.)
Actually, this seems like such an obvious idea that I’m 100% sure it must’ve been considered before, but I can’t find any related discussion.
Attila.
- Previous message: RFR [9] RandomFactory should be in the jdk.testlibrary package
- Next message: AbstractList etc. functionality as interfaces with default methods?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]