@Supported design issues
philip.race at oracle.com
Sun Mar 17 16:10:58 UTC 2013
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
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
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
> 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.
More information about the core-libs-dev