yes, i agree there are too many libraries in the JDK that only make sense with an "historical perspective" ... and that perspective should not be necessary when you have a job to do now ... an API should have a single self-consistent logical approach that speaks for itself ...
in many areas (Java2D, Printing, Threads, AWT/Swing, Dates, etc ..) there are 2 or 3 complete ways to approach using the library ... newer approaches are generally better (having corrected mistakes of the past) but they are often built on older packages that must therefore still be included in the JRE ... so a lot of time can be wasted sorting out what to use and what to ignore ...
it would be great to see the duplication removed, so the JDK provides one standard approach to each area ...
and i agree, it would also be great for standard libraries to make use of improved APIs internally ...
really fixing the JDK in this way would mean breaking backward compatibility in a really big way ... this will not be popular and i imagine there would be calls for compromise ... but that might do as much harm as good - in the past, with the noble intention of maintaining backward compatibility, new APIs were often wrapped around old ones or depended on older classes (eg. Swing extends AWT) but this practice has created the vast size, complexity and confused muliple approaches the same task that people now want to fix ...
so the more i think about it, the more the proposed Java Module System (JSR 277) seems crucial to how well deprecation can be managed ... if it can address these issues, allowing deprecated classes/packages to be loaded in versioned legacy modules, then removing deprecated APIs can hopefully be done without messy compromises and without breaking backward compatibility ... and with Sun's Java now GPL, the time is right for "many eyes" to contribe to cleaning things up ...
i really hope JSR 277 can deliver this - the opportunities seem really great ... |
java.net RSS Feeds
