Add resetValue() to EditableValueHolder? Blog
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
12 Comments
-
-
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). // -
Is any component lib implementing EditableValueHolder without extending UIInput? If not it would be save to add the method to the interface. // -
And that is breaking backward compatibility. I don't think you would want component authors to have to maintain 2 versions of their components. //
-
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 //
-
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 ;-) //
-
@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. //
-
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. //
-
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. //
-
BTW. Randahl, yes it was funny on Saturday :-) //
-
I definitely agree with Randahl. Take advantage of the fact that it's a 2.0 release. //
-
Break it! Backwards compatibility is for wimps. ;-) //
mriem Sep 10, 2008 2:15 AM