One of the worst things about Java is the lack of a language level solution to the fragile base class problem. In the absence of a solution, the JSF EG has resorted to creating subclasses of interfaces, appending a digit to the interface name, and adding the methods there. For example, we created ActionSource2 as an extension ofActionSource just so we could support for the Unified EL in JSF 1.2.

The fragile base class problem is one we commonly face when evolving an API and JSF is no exception. JSF Spec Issue 327, filed by Trinidatd stalwart Matthias We?endorf, requests the addition of resetValuedirectly to EditableValueHolder, which would clearly break existing implementations of this interface. At JSFOne 2008 last week I spoke with Herr We?endorf and he asserted that most of the implementations of this interface will have aresetValue method, ore one very similar to it, in general. Therefore the pain of adding it toEditableValueHolder directly outweighs the nonsense of creating EditableValueHolder2 just for adding this method. It's a compelling argument, but I want to poll the community before doing it.

Please comment if you have an opinion about this minutia of JSF 2.0 design.

Technorati Tags: edburns