|
The decision so far to keep every deprecated class and method forever effectively makes the entire idea of deprecating things one big joke.
Deprecation is meant to be a mechanism to mark APIs for future removal, if that removal never comes you could just as well not mark it as deprecated. Another annotation like "@PleaseDontUseInTheFutureAsINowThinkItWasABadIdeaToDoThis" would be more correct...
Users may be surprised to see ancient applications fail when updating their JVMs, but they're hardly unused to that. When upgrading their operating systems old applications also fail from time to time (or display unexpected behaviour). They're used to that, see it as either a reason to not upgrade their OS or a reason to upgrade their applications with their OS. The former group shouldn't be a problem for you as they're not potential customers for your new versions anyway, the latter group might not have been a customer but will be now.
All that's really required for people shipping Java applications is to not only list a minimum JVM version but also (if known) a maximum JVM version or a notice that the application can't be guaranteed to work in its current version on JVMs with a version of x.xx or higher.
And that would already be more than most software publishers do. They just tell the user that the system is tested on this and that version of the targeted operating system and that they're on their own if they want to use it on anything else. That too is accepted by endusers, so why should Java be special and aim to guarantee backwards compatibility into eternity? |
java.net RSS Feeds
