On 05/23/2011 05:00 PM, Marek Potociar wrote:
>
>
> On 05/23/2011 04:31 PM, Bill Burke wrote:
>>
>>
>> On 5/23/11 10:05 AM, Marek Potociar wrote:
>>> On 05/23/2011 03:49 PM, Bill Burke wrote:
>>>> Adding methods to an interface does not break backward compatibility. Removing and changing method signatures does. The
>>>> Servlet API, for example, has added numerous new methods over the years.
>>>
>>> The statement above is true only if it is 100% clear that users MUST NOT implement the interface. Otherwise the user
>>> code fails to compile against the new version with new methods added to the interface.
>>>
>>> I am not sure if such constraint holds true also for our case, esp with interceptors/filters in play.
>>>
>>
>> I'm not convinced that this constraint you talk about is observed in the Java EE specification process.
>>
>> As a framework developer and servlet Filter developer I've been forced many times to implement the ServletRequest and
>> HttpServletRequest interface. This is just one example I can think of off the top of my head.
>>
> It would certainly make our lives easier. Let me check with the EE spec leads.
All right, the still steaming-hot and fresh information is that if it is a general-purpose interface, then we want to
avoid extending the interface[*]. However, if it is an interface expected to be implemented primarily by the
container/implementation provider, then we should be able to extend such interface.
Fortunately, Request/Response fall into the second category.
Marek
[*] For JavaSE 8 there is a proposal that should allow gracefully extending any interface (by specifying some default
impl or something like that).