On Thu, 2007-08-23 at 10:35 -0400, Simon Lessard wrote: > Hello all, > > Reading the JAF 1.2 API I found the following: > > getResourceBundle > public java.util.ResourceBundle getResourceBundle(FacesContext ctx, >
> The default implementation throws > UnsupportedOperationException and is provided for the sole > purpose of not breaking existing applications that extend this > class. > > Returns: > ResourceBundle for the current UIViewRoot, otherwise null > Throws: > FacesException - if a bundle was defined, but not resolvable > java.lang.NullPointerException - if ctx == null || name == > null > Since: > 1.2 > > Both are exactly the same. However, I wonder why the doc says the > default implementation provides that method only to not break existing > applications when JSF 1.1 did not even have that method... I really > cannot figure that one out. Can anyone enlighten me? I think what they are saying here is that they really wanted to add an abstract method here, forcing all the subclasses to provide an implementation. However if they had added an abstract method, then they could have broken existing code. Suppose someone had subclassed this class in JSF1.1, then tried to load that binary subclass into memory with the JSF12 library present. Any attempt to instantiate their class would fail, because their class is now technically abstract - the ancestor class has an abstract method that has not been implemented. I'm not actually sure whether then exception would happen when the constructor is called, or when the class is loaded into memory, or whether for some JVMs it would actually work unless someone called the method that doesn't exist, but regardless you can see that adding an abstract method to a class is a change that breaks existing code. The workaround used here is to make sure the method is not abstract, by providing a dummy implementation that just throws an exception. When subclasses of the old version are now loaded, they work fine as long as no-one calls that new method. However for code that really has been written for use with JSF1.2, the subclass should have a proper implementation of that new method. And so you can safely call that method as long as you know the concrete implementation is not legacy JSF11 code. Regards, Simon
