Question

If you had the chance to significantly change/update Java’s classpath libraries, which things would you add/update/change/deprecate/remove?

Answer 1

• Restructure all the various aspects of the currently far to monolithic class library into seperate modules with lower interdependencies. This would require to seperate interfaces and provided default implementations into distinctive class hierachies (similar to what exists for the SAX API already). Rationale: allow deployments with stripped down class libraries and additionally enable third party replacementes and extensions of certain central aspects (crypto, network protocols, i18n, …).

• Redesign all collection classes and some of the java.lang classes into much smaller building blocks that can be assembled into more flexible and more powerfull data structures (along the philosophy of the Google Collections classes). This would offer far more context independant behavioural interfaces, like i.e. CharSequence or Comparable.

• Provide more platform specific (Extension-)APIs and implementations that cover as much as is reasonable of the supported platforms (and grow with them) and accept that code that is using these classes will not be portable without extra effort from the developer. This is meant to allow the creation of non trivial software that is able to compete with native software in terms of usability, usefullness and general perceived quality. These APIs would for example allow access to block devices, vt100 terminals, the Windows registry etc.

• Redesign Swing in a multilayered way (i.e. controls on top of basic building blocks on top of a graphics primitives API) and make it far more polymorphic. I.e a single Action interface with a single method perform instead of lots of special Listener interfaces. Additionally I’d offer a wrapper framework that encapsulates native GUI components (in the spirit of my previous proposal).

• Try to find a better way to handle security related access restrictions for sandbox environments that doesn’t limit the overall flexibilty of many imporatant fundamental classes. Currently language features originaly intended for design purposes are heavily abused for security purposes which has led to rather static and nonpolymorphic classes and APIs because they could be expoited from within a sandbox if they were more open (and the approach still failed to be secure enough many many times).

• Provide a less naive serialization system that supports weak references, has error detection and supports class evolution.