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.
