@Supported design issues (original) (raw)

Phil Race 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 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.

More information about the core-libs-dev mailing list