Adding Generics to the Java language isn't going to revolutionary change the status quo. People extremely over estimate the value of language constructs in the overall scheme of providing compelling solutions to a customer.
Brian McCallister has a provoking blog entry about the state of Java (the language) and opines that "what doesn't grow dies". Bill de Hora responds with an earlier piece where he opines "Java as a language and platform is reaching a natural level of incompetence". He further recommends "Adaptive businesses need adaptive systems. Adaptive systems need adaptive languages".
This very issue was explored by Robin Sharp in his piece "Programming Language Lifecyles - Where's Java At?". He opines "Certainly we are now getting into the Inefficiency phase of the Java Lifecycle. J2EE and EJB form a ready made architecture that is expensive to develop.". Unfortunately, he provides an extremely weak recommendation:
One of the most promising areas of research is the design of the so called 'component-oriented' languages. These differ from object-oriented languages in that they offer messaging, properties, events, sessions and homes all built into the language.
The commonality of opinion is that we need a revolutionary change in the Java language. However, I would like to point out Rickard Oberg's recent thoughts on this matter titled "AOP - academic vs community". Here Rickard perceptively points out the habit of the academic community to add new language features to solve a problem:
Pretty much all of the papers I've seen so far create a new language, each introducing a bunch of new keywords. While the accompanying explanations make the new languages seem logical (although the examples, while simple, are almost always incomprehensible), the result is more than a bit difficult to follow and understand. It's like adding new kinds of pieces of lego to the toolbox: looks nice, but how in the world do I use 'em?
I think that these differences in approach to the whole thing has to do with our different restrictions and mindset. In "the real world" creating a new language is not such a great idea, since then there would be no tools that worked with it. AspectJ is example of an academic AOP project that is almost becoming viable due to tool support in Eclipse, but even that is stretching it. At the same time, for a researcher it is more natural to create a new language than try to use Java as-is, since in research one is more interested in getting the (in some sense) best solution and not necessarily the most practical solution.
I reckon that the academic community's inclination towards "writing a new language" stems from a deeply ingrained bias. That is the academic community has deeply invested in a thinking style which I would classify as "Static Reasoning". Steven Wolfram explored the roots of this in his massive book "
A New Kind of Science", that I highly recommend. The essence of Wolfram's work is that he shows the limitation of analytic forms to model and study complex systems. He reasons that if computers had been invented before calculus the manner in which we do science would be vastly different. By the same line of thinking, we should invest more effort towards dynamic instance based systems as opposed to statically provable language features.
Adding Generics to the Java language isn't going to revolutionary change the status quo. Just as syntactic sugar in the C# language doesn't automagically make C# more compelling than Java. People extremely over estimate the value of language constructs in the overall scheme of providing compelling solutions to a customer.
For the past couple of weeks I've been compiling a list of projects that are written in Java. You may have noticed that the lists contain surprisingly numerous projects covering almost the same functionality. However, each project isn't a simple set of library components, rather they are comprehensive solutions to oft encountered problems. My point however is that, no amount of syntactic sugar is going to make it drastically easier to put together these projects. However, the big question in my mind is how can you build much larger applications (i.e. Ideal CMS) by composing these different projects.
Legacy Applications will always exist whether it be written in Java or some other language. To believe that a new programming paradigm will come along that would make it compelling enough to rewrite them is a complete fantasy. Java as its present form (static typing and all) is completely adequate for programming in the small. The big question is, "how do you do programming in the large?" Adaptive Components are the answer. Language change are mere conveniences, however someone needs to figure out how to build adaptive components. Till then, all rants about new language features are all barking up the wrong tree.
The languages changes proposed for 1.5 are certainly welcome, and they will indeed increase quality. But I don't think they will have a particularly large effect on the productivity of Java development.
What would have a large effect are simply more libraries. More precisely, Sun seems to have stopped building libraries "vertically" (to higher levels of abstraction), and has opted to place their efforts on building libraries "horizontally", to a wider range of domains.
Swing was once described by Gosling as the "Boeing 747 cockpit of UI toolkits". Sometimes a Cessna is all that's desired. A library built on top of Swing, which aids in building common items, would be vey beneficial to increasing productivity.
Similarly, a library built on top of the Servlet API could also aid enormously in building web applications. The same goes for JDBC.
Such libraries would not be useful in all cases, of course. But they could target the most common application designs. Perhaps the construction of such libraries is up to the Java community as a whole, and not simply Sun.