@Supported design issues

[Phil Race]

1. I suspect that the percentage of deprecated APIs is less than 0.1 % ..
     So removing 1 ouf every 1,000 methods is not exactly going to make
    a huge difference here.

2. Some methods were deprecated at a time when the policy was to
     encourage people to use "newer" API, even though there wasn't
     anything very wrong. with the old one.
     For example Component.show()/hide() were deprecated
     in favour of Component.setVisible(boolean) although as far as I know
     there's absolutely no problem with the former.
     So such a policy would not be something you could apply automatically
     you'd need to go examine each case to understand it.

3. Removing methods *from the doc* and *from the runtime* each
     have their consequences, from the doc would discourage new uses
     but make it harder to understand old code. I think a long ago 
ill-fated JSR
     for javadoc improvements pondered hiding deprecated methods if
     you didn't want to see them. Remiving from the runtime would
     break apps, and in some cases people don't have the option to change
     and fix.

-phil.


On 3/16/13 2:10 PM, Daniel Latrémolière wrote:
>> I'm continually surprised by developers I meet at conferences who
>> (sometimes angrily) demand that deprecated APIs be removed, so I think
>> the reality is a mixed bag -- not that it matters a great deal either
>> way.
> Just a personal opinion as a developer. Java APIs are very big and 
> removing deprecated APIs can reduce this size. It will help solving 
> this question: "what can be the name of the currently needed 
> class/method in all these APIs?", which is very important, 
> particularly for new Java developers, frequently lost in these 
> numerous APIs.
>
> Readability is the biggest design feature of Java, then I think there 
> is some logic if developers ask for removal of deprecated API, because 
> it will improve readability of APIs.
>
>