> Trust me ... you don't want to read all the EG threads on that topic > :-). But the short answer is, consider what happens in a future > version of JSF, when (for good reason) a new method signature is added > to the Renderer API. If it were an interface, you've just broken > every current implementation in the world. As an abstract base class, > you can add a default implementation that mirrors the previous > behavior, so the only potential breakage is if an implementation had > their own version of that very same method signature.
It seems like you could get the best of both worlds with an interface and an abstract class that implements it. Since this has been well-vetted by the EG, I'll accept the reasons it was done without an interface. > An actual instance, of course, must be of a concrete class that can be > instantiated. But whether that concrete class extends an abstract > base class, or implements an interface, is irrelevant to how many > copies there are. In this particular case, it simply has to be that > "instanceof Renderer" returns true, since the JSF implementation is > going to cast it to this before calling its methods. So, it sounds like the JSF implementation *does* get to choose whether or not javax.faces.render.Renderer is an abstract class or in interface since an "instanceof Renderer" check could be done for an instance of either. Am I understanding correctly? > > Craig >
