On 05/13/2011 01:36 PM, Bill Burke wrote:
>
>
> On 5/13/11 7:28 AM, Marek Potociar wrote:
>> While I can personally see some benefits, that's not the common Java EE strategy. I would be very skeptical about
>> proposing to break BW compatibility.
>>
>
> Are you even allowed to break BW compatibility? I know in the EE group you can't even remove an API unless it is
> deprecated for at least one EE release.
>
Removing one major release after deprecation is a commonly applied strategy in many Java projects, but it would be very
difficult (read almost impossible) in EE or SE. So the simple answer is "No".
Even marking something as deprecated is not particularly simple too. That is one of the reasons why I am reluctant to
add new specialized API in domains (e.g. client-side caching) where we don't seem to have a solid past experience with
designing proprietary API for the problem. If we screw it, we'll have to live with it forever...
Btw. as a general guideline, deprecation is a way to recommend to developers in a VERY visible manner, namely a compiler
warning, that a certain API element should no longer be used. We should use it reluctantly and only after careful
thought, primarily for "highly radioactive" things. This is because unlike in C, people tend to take warnings from the
Java compiler very seriously. They feel that they must've done something wrong and they really should fix their code to
avoid the warning.
Marek