jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: How to add new methods to abstract classes?

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 13 Mar 2013 20:16:44 -0700

>>>>> On Mon, 11 Mar 2013 16:22:59 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:

AS> While reviewing the new Application.getFlowHandler() API:

[...]

AS> I am reminded again of a topic that came up during 2.0 spec development
AS> (and maybe again in 2.1): how to go about adding new methods to abstract
AS> classes.

Yes, I recall that Blake had some strong opinions about this as well.

AS> We've got a variety of options:

AS> 1. Make the new method abstract.
AS> 2. Implement a "real" solution in the abstract class.
AS> 3. Implement a transparent, but stubbed (no-op) solution in the
AS> abstract class.
AS> 4. Implement a non-transparent solution (eg. return null and require
AS> the caller to check for this return value).
AS> 5. Thrown an UnsupportedOperationException.

AS> We tend to do either #4 or #5, which in my mind are the worst
AS> options.

I tried to do #3 as frequently as possible in 2.2.

AS> I know that it is too late to do anything about this for 2.2, but wanted
AS> to send this out in the hopes that we'll discuss this in more detail
AS> when 2.3 starts up.

AS> I guess while we're here, I might as well say that I think that this:

>> + * For the purpose
>> + * of backward compatibility with environments that extend {_at_code
>> + * Application} but do not override this method, an
>> implementation is
>> + * provided that returns {_at_code null}.

AS> Is not doing anyone any favors. Instead of making it clear to the
AS> Application subclasser that their subclass is failing to implement a new
AS> responsibility, it hides this fact with a non-functional default
AS> implementation. As such, instead of finding out about this failure at
AS> compile time (as would be the case with #1), you won't find out about
AS> this until some later point when your application fails in some more
AS> subtle way.

On the other hand, isn't in the case that if you have an application
written for an earlier version of the specification that decorates
Application, and therefore won't even cause that new API to get called,
because it is not using the new features, you would rather not have the
application blow up at compile or link time?

In any case, I hope we can give you more satisfaction on this point in
the next release.

Ed

--