Bruce Eckel says Java is at an “Evolutionary Dead End”. His perspective is that retrofitting newer features into Java is making it absurdly complex. He states the choice is between no more evolution or breaking away from the past. In any other scenario he suspects things are only going to get worse. As a passing by remark, he proposes moving on to Scala as an exit strategy, if Java continues to evolve while honoring backward compatibility.
Technically his point is valid, realistically what are the millions of Java developers who build Java applications at thousands of enterprises going to do if they can’t incrementally take advantage of some of the newer features? It may be possible for Ruby or even Python to radically break away from its earlier versions and start on a fresh slate because not only do they have lesser number of deployments but on an average they have programmers smarter than the average corporate journeyman.
Java has evolved from being a replacement for C++ to an all pervasive cross domain programming language. One of the primary reasons for this growth has been the abundance of features, availability of commercial and open source implementations of these features and wrapping up of these features in all sorts of APIs, with the assurance of stability.
If we drop everything and restart, won’t Java be a completely new language? How would we guarantee we get everything right this time around? Which portions of Java will benefit from reinvention the most? What will we do while we are busy reinventing, knowing what we are doing is soon to be rendered obsolete — it won’t get done in a jiffy in any case?
Since Java is Free, it could be forked a variety of ways (the forks having different names). As has happened with other projects, only the forks with real staying power and support (likely from a company or a consortium of companies) will thrive. And, of course, forks that don't support popular APIs/standards/JSRs will only be dooming themselves.
It is possible, though difficult, to maintain legacy *functionality* while still moving forward. It is important to maintain this functionality, though, not by maintaining legacy code, but rather by re-implementing the (well-documented) functionality on top of new code.
So, the approach involves a from-scratch implementation of Java (or some new name), which eventually passes all of the unit tests (TCK?) by re-implementing legacy features on top of the new framework. A lot of work, yes, but a wonderful result where future evolution is not directly anchored by legacy code.
wake up guys! java is really duying. everybody can see that.
Um, first, Bruce isn't necessarily correct here, and his view may well be slanted due to joining the FLEX bandwagon. In any case he was referring only to Java-the-language and it's clear there is a lot more to Java than the language. I suppose an argument could be made to freeze java-the-language and allow all the ferment and growth and change to be made in other parts of the platform. I also agree with Bruce that the other languages which run on java-the-platform are of strategic significance.
@David, The "Flex bandwagon"? I like that. Like Adobe Flash isn't the platform for all viable video on the internet. Wait, you work for Sun, I get it. How's the JavaFX bandwagon coming along these days?
@Tim O'Brien: Most Java/Flex usage has absolutely zero to do with video, so I'm not sure why you brought that up. There *is* a "Flex bandwagon" right now (with good reason; the Ajax model is tricky to do well still).
Java was not designed in mind for what it is being used now. A programming language is good for a domain when it makes the things that programmers do in a domain, easy. Currently, Java is verbose because it does not do these things well.
I do wish that Java gets a major overhaul. But why should we have only one language? Why not have a second, properly designed language? .NET does it. How about a C# for the JVM? It is an ECMA standard after all. Groovy is great and addresses all my concerns with Java but I would like to see it supported as a first class citizen in Eclipse and in Netbeans.
Yes, I do know that they are already a large number of languages for the JVM. But without tool support they are not viable choices. What we need is a well marketed language alternative. Marketing is what made Java what it is today.
Let's treat Java as C, a language that stays close to the JVM and for API authors and promote a second language for everyday productivity.