SDTimes publishes this news article: Slimming Down Java: Protocol laid out for deletion of SE features.
“After years of bloating with new features, Java SE may begin to slim down over the next few years. Thanks to some new guidelines added to JSR 270, the Java SE 6 proposal, the JCP can now move to discard older, lesser-used features of the platform.”
Java SE 6 goes even lighter than the lightweight J2SE 5. What API would you like to see deleted or even added to the Java SE 6?



The java.util.Date and java.util.Calendar API's are next to useless.
I don't think they'll ever be removed (would break too much existing code), but I wouldn't mind seeing them gone. Joda-Time is mature enough that it should simply replace the existing calendar API's in JSE/JEE (might have to be trimmed down for JME).
If you need java on diet for applets just use flex2. If you agree to install jvm just don't care how huge it is.
Date and Calendar API useless?
Perhaps I need some clarification of what replacements would be, but to me, storing a Date and manipulating it is the really basis of a LOT (let me emphasise this... I mean HECKUVALOT) of apps out there. Wether you work with actuaries, you work on schedule/time related apps, I don't see how a decent programming language could work. For the record, I admit learning Calendar, GregorianCalendar, Date, DateFormat etc. is kinda tricky and a steep curve, but it is also the most flexible date/time manipulation, abstraction, internationalization format I can conceive.
Some sorts of inner classes could disappear. I never saw use for or method inner classes.
I specially dislike anonymous inner classes (for the sake of readability), but I know there are a lot of people who think it's too much trouble declaring a small private named class. Sometimes it's too hard to figure out a name...
The Logging API should be removed in favor of "let's not put the kitchen's sink in Java".
I second removing the logging API. In fact any of the APIs that magically discover third party libraries should be removed. I'm sure that kind of decoupling sounded like a good idea at the time but really... are there even any two versions of the same xml parser that you would trust to be 100% compatible?
There should be a time when they disrupt with backwards compatibility, and correct the mistakes of the past, like .NET did on version 2.0. The previous JVMs will always be there for old apps.