its not a matter of "can't be bothered to update" (i would aim to release new versions or updates annually) but of wanting non-technical home users to have an "it just works" experience. i agree, customers can only reasonably expect so much, but i would rather have customers who are happy because they got more than they expected than ones who are unhappy but resigned to fact that it would be unreasonable to complain ...
the more often a non-technical home user has to upgrade, the more factors (app version, JRE version, operating system version) are involved in the upgrade the more chance of something going wrong and/or the end users switching to a competing product ... the simplest upgrade path is no upgrade at all ...
also, i might be wrong, but i imagine if an end user updated their JRE, that it would still succesfully load a class containing a call to a method in a deprecated API, but would then fail if and when the method is called. (is this correct?) from a non-technical end users perspective, that would produce unexplainable behaviour ... a negative experience ...
the Java Platform(s) is/are huge and obviously a lot of different developers have an interest in how it/they evolves ... at the end of the day, Java is strongest on the server. so server side developers will likely have the most influence ... and rightly so ... as a webapp developer, i see cleaning out the cruft and even rewritting core APIs (eg. URL and URLConnection, ...) as very appealing and i imagine other server side developers might feel the same way ...
... but desktop Java is gaining a support at the moment and i wonder how a future regime of removing deprecated APIs would effect its viability, given that deployment is already its biggest problem ... on the corporate desktop, which is a controlled environment, upgrades can be managed by technical staff, but their is no helpdesk for home users running browser based "Rich Internet Applications" and the sort of dekstop apps that get featured on www.java.com ...
of course, if the JRE could automagically load older versions of classes using "legacy modules" with the end user knowing the difference, there would not be a problem ... |