Bruce Eckel thinks Java may be getting too many features for the wrong reasons:
People lived tolerably for many years, then suddenly it became essential that generics be shoehorned into the language. This was remarkably coincidental with the appearance of generics in C#, which also appeared to produce several other features in Java 5. It seems that the urgency of these features came not from solving true problems in the Java language, but in Sun trying to maintain the perception of competitiveness against Microsoft’s C#. This is probably not so far off the mark, because the reason that Java had to be rushed out in rough form in the first place was the belief that there was a market window that must be captured. A programming language designed by following marketing impulses is eventually going to end up chasing its tail.
When is should be gaining clarity:
If Java is to be saved at all, it needs to become like C; a workhorse that you can rely upon. In fact, any future changes to the language need to be things that simplify and clarify the language and its use (say, fixing the classpath problem), and flesh out (for example) incomplete libraries that have languished (like JMF).
But we need to become especially conservative when considering major, fundamental language features like closures which, while they can be very appealing in theory, may have a cost that is too great in practice when they are forced into a language that values backward compatibility over the clarity of its abstractions.