Javas development as a language has been effectively stalled for years now. Other languages, better suited to the kind of rapid-fire development pace needed today, are eclipsing it. Worse, Oracle doesnt have the kind of track record with software development to make people think theyd be able to drag Java development currently treading water back onto dry land.
Oracle probably doesnt want Java to become a relic of an earlier age. But theyve got their work cut out for them.
Two wheels in the mud
There are two major reasons Java has become increasingly hidebound and reactionary.
The first and biggest is the way Sun has historically valued backwards compatibility over expanding Javas capacity and flexibility, except where the latter can be accomplished by things added on outside the language itself. The second is how development on Java the language has stagnated as opposed to development on the environment that the language runs in the Java virtual machine.
The first problem, backwards compatibility over agility, stems from good intentions. The amount of Java code out there is more than incentive enough to make sure tomorrows Java engines can use todays code. But my opinion is that Sun has for too long valued backwards compatibility over moving Java forward as a language so much so that Javas prestige as a language is being eroded.
The things that could make Java a better and more agile language might well come at the cost of making it compatible with earlier editions of itself. Lack of agility means the language, in time, falls from favor with people who do cutting-edge work.
If you have your pick of languages (and programmers), why go with Java when theres C#, or Ruby, or Pythonor, for that matter, F# and Scala (one language which runs in the Java VM)? Especially if youre in a hurry, and those other languages better support the kind of rapid prototyping you want?
Its not that Java the language runs slow; its that development in Java is the real bottleneck, because other languages are learning to avoid those issues.
For proof that work on Java has slowed to a crawl, look no further than the release schedule. The last time Java had a major update was in September 2004, with the release of Java 1.5. 1.6, which came two years later, was more like a 1.5.1 edition. Java 1.7 was supposed to have been out late last year; the newest projection is sometime late this year.
Heres another fun experiment: take an existing Java programmer and give him an app written in 2003 or so or, better yet, take a circa-2003 Java hacker and show him something written today in the language. Odds are both of them will have no trouble understanding whats in front of them.
Its harder to say the same thing for a C# programmer. The vintage 2003 guy would be scratching his head at innovations like LINQ and WPF. Baffling as those things may be to a newcomer, they make it possible to do more advanced things that much faster.
The other reason Javas stagnated as a language is because the aforementioned runtime engine for Java has been garnering more attention than the language itself from the people that matter. The JRE has become a way to not simply compile and run Java, but many other languages. Consider JRuby, a JRE port of Ruby, which produces amazingly fast codefaster than the native Ruby system itself.
Much emphasis was put on the JRE as, again, a way to make Java run that much faster. But more often, thats not the real bottleneck its the development cycle that Java forces on people who program in it. Projects like Apache Struts, for instance, might not be required if Javas internal development had been more cohesive and forward-thinking.
No criticism of Struts itself intendedjust that its a sign that whats weak within Java has time and again been propped up, pun intended, by third parties.
Spin all this positively and you have a way to say Java has maintained excellent backwards compatibility. But its also a sign of how little Java has evolved internally, and is in danger of being overtaken.