Skip to main content

Add resetValue() to EditableValueHolder?

Posted by edburns on September 9, 2008 at 8:51 AM PDT

One of the worst things about Java is the lack of a language level
solution to the href="">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


as an extension of ActionSource 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. href="">JSF
Spec Issue 327, filed by Trinidatd stalwart Matthias Weflendorf,
requests the addition of resetValue directly to

which would clearly break existing implementations of this interface.
At href="">JSFOne
2008 last week I spoke with Herr Weflendorf and he asserted that most
of the implementations of this interface will have a
resetValue method, ore one very similar to it, in general.
Therefore the pain of adding it to EditableValueHolder
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

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

Technorati Tags:


I definitely agree with Randahl. Take advantage of the fact that it's a 2.0 release.

BTW. Randahl, yes it was funny on Saturday :-)

Randahl, ActionSource2 is a different beast. Adds dependency to a different layer => Unified EL (JSP 2.1). I'd love to see that guy die, but that is really hard and not that easy, b/c that would actually really break things. But I have to say EditableValueHolder2 should NOT be introduced.

Randahl provided very good arguments against introducing EditableValueHolder2. It is hard to add more point to that. I'd like to see that ActionSource2 is gone. By the way It's time for EL to include support of parameters.

@mriem Can you describe the breaking backwards compatibility, if every component lib extends from UIInput or already contains the resetValue() method. MyFaces Trinidad's UIXEditableValue contains a resetValue() method (only check the 1.2 codebase) and is not extending from UIInput only implementing EditableValueHolder. So far I know MyFaces Tobago and MyFaces Tomahawk just extending UIInput.

I am pretty sure that every component vendor that takes jsf2 serious will have to do some work, to leverage the other new features.... Maybe I am wrong

And that is breaking backward compatibility. I don't think you would want component authors to have to maintain 2 versions of their components.

Is any component lib implementing EditableValueHolder without extending UIInput? If not it would be save to add the method to the interface.

Adding methods to an existing interface doesn't brake existing code (pre-jsf 2.0 component-libraries) by itself. What breaks backwards compatibility is calling the new method just by relying on the fact that a class implements an interface without prior knowledge whether this class was compiled against the current or an older version of the interface (one would get a NoSuchMethodError in this case). So if we would decide to add 'resetValue' directly to EditableValueHolder, the JSF-implementation would have to know by other means (e.g. a version element in the TLD) which version of the JSF-API is implemented by the component. (And components-authors maintainting an older version of a component-library would have to compile against the pre 2.0 version of the API too).

I would not favor it at all. Backwards compatability is a strong Enterprise requirement, changing that would break it and as such it could hamper adoption of a newer application server. Wouldn't you then need to support 2 implementation versions of JSF on the application server?

In general I always favor evolving the existing interfaces over introducing additional alternative interfaces to the same classes. When we introduce extended interfaces such as ActionSource2, Graphics2D or EntityResolver2 we delude ourselves into thinking we are saving the world a lot of resources by keeping backwards compatibility. In reality however, we are gradually reducing the clarity of our APIs, making the API's more time consuming to understand and use which eventually leads to a net loss of time. Take Graphics2D for instance - it was introduced all the way back in Java 1.2 in order not to brake the existing AWT painting APIs. And sure that instantly saved developers the time consuming task of upgrading to what would have been a non-backwards compatible Java 1.2. However it also meant that until this very day developers are still forced to type cast their Graphics instances to Graphics2D instances in order to use the modern API. I think many Swing and Java2D developers will tell you that this is a drag. Using a less clear API is time consuming and unlike the one-time time savings we got from not having to upgrade, the cost of working with a less clear API goes on forever. If you were working on a minor upgrade (a JSF 1.3 so to speak) I would understand why you would not want to shake things up, but if JSF 2.0 is not the time to do a cleanup - when would you ever? I love the Germans' saying in this regard: "Weniger aber besser!" - it is no wonder they are renowned for great technical design. Randahl PS: To Ed - yes _that_ Randahl (in the red shirt)... thanks for a really fun night on Saturday ;-)

Break it! Backwards compatibility is for wimps. ;-)