I have a legacy interface that looks like :
/** Never change *a line* of this or some angry monster will fall from the opening skies talking obscure reasons not to mess with this */
public interface IllFindStuffNoWorries<STUFF> {
STUFF findById(String id);
STUFF findById(Long id);
STUFF findById(UUID id);
... and so on
}
(Which is pretty inconvenient since I never know what type of id it expects)
But it turns out all the STUFF of the project has a method getId() that returns one of the types that the implementation-associated IllFindStuffNoWorries is willing to handle.
So I introduced a:
public interface IveGotId<ID> { ID getId(); }
Which is now extended by all my STUFF-s, allowing me to introduce:
public interface TypicalFinder<STUFF extends IveGotId<ID>, ID> { //get it ? typical because types ... ha ha that sounded hilarious in my head ...
STUFF findById(ID id);
}
So I had a Something SomethingFinder which I modified from:
/** Change as little as you can there */
public class Something {
...
String getId(){ return id; }
...
}
public interface SomethingFinder extends IllFindStuffNoWorries<Something> {}
To:
/** Change as little as you can there */
public class Something implements IveGotId<String> {
...
@Override String getId(){ return id; }
...
}
public interface SomethingFinder extends IllFindStuffNoWorries<Something>, TypicalFinder<Something, String> {}
While this would have been fine in java 7- (according to years old memories), compiling it with java8(+?) yields me this :
/home/stackOverflowUserAr3s/projects/hot-mess/src/main/java/some/where/impl/SomethingFinderImpl.java:12:42
java: reference to findById is ambiguous
both method findById(ID) in new.mess.TypicalFinder
and method findById(java.lang.String) in old.mess.IllFindStuffNoWorries
match
Is there a way to make this work ?
Am I trying to rely on an outdated thinking ?
Are @FunctionnalInterface-s a sort of way to go in my case (just one method that interests me) ?
Those are interfaces, extended by an interface ... This is not some funky intent of multiple-implementations, that is a conjunction of contracts that conveniently overlap and can both be satisfied by a single implementation.
