Some of your points are correct. Others I would strongly dissagree with.
10. Delete all deprecated methods, fields, classes, and interfaces
I have been saying this for years. This has lead to people not using Calendar and still using the broken Date methods.
9. Fix incorrect naming conventions.
This is reasonable.
8. Eliminate primitive data types
I disagree.... While there are areas that the types can be improved i.e., BigDecimal, removing the primitive types is the wrong answer. One of the advatages of java is its preformance. While the oo purest may think all objects everywhere, it leads to preformance issues and actully clutters the code unless you add operator overloading. Operator Overloading is a bad idea and should never be added.
7. Extend chars to four bytes.
6. Fix threads.
should have already been done
5. Convert file formats to XML.
I have had this conversation with many other java developers over the last year. This sounds good on the surface, but it should be optional. For property files and manifest it is a greate idea.
However, since RMI is done through serializing objects the overhead of xml would dramatically impact the use of EJB's. It would require more cpu cycles and network bandwidth with no gain for the users.
4. Ditch the AWT.
Sure... sounds good... I don't do AWT/SWING... HTML/XUL/JSP is the future
3. Rationalize the collections.
Agreed. Make the interfaces behave the same and make them all threadsafe.
2. Redesign I/O.
1. Redesign class loading from scratch, this time with human interface factors in mind.
The classloader issue has bit me a few times, but the benifits of the segmented loader is great. I can control aspects of security buy using different classloaders. Not sure there is a way to adjust how the classloaders work without breaking the segmented nature of the loaders. If fixing them means removing the segmented nature, it sould not be done.