|
|
Featured White Papers
Sponsored Links
-
Slow Apps? Overloaded DBMS? - FREE Download
FREE Download Feb 14 - March 7th Eliminate bottlenecks & maximize performance ScaleOut StateServer®
Java isn't dead -- it's just fossilizing
Submitted by Josh Fruhlinger on Fri, 10/02/2009 - 00:11.
So here's a thing that everyone thought was going to be in Java 7 and now isn't -- the Swing Application Framework (which in January I called a JSR to watch in 2009, whoops). Work on it hasn't progressed, now it's being pushed back to Java 8 maybe, etc. It wasn't really a core bit of the language, though it would have given heart to those worried that Sun was done with Swing.
But there's a larger sense that big fixes and changes aren't being added to the language any more, closures being the big one that seems to have such an intense following. In a smart and provocative blog post, Chas Emerick says that you should learn to love the new, more stable Java language. I won't rehash his arguments in depth here, but he basically says that Java is now a systems language, like C; making big changes to it would be counterproductive, because all the action is taking place in the JVM languages built on top of it. Java actually needs to be stable, because without being able to depend on such stability, folks wouldn't take the time to invest in work on those languages. By becoming necessary, Java ceases to be interesting.
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2010 Infoworld, Inc. All rights reserved.
The problem with that
The problem with that approach is that the boundaries between the other JVM languages then become more ad-hoc.
If BGGA closures had been accepted, the VM would generate java.lang.function types in a similar way to array types, and the other languages would be able to use those. Instead, for example, Scala has its own Function2, Function3, etc., which no other language knows anything about.
Of course the language implementers could agree to share some interfaces, but without support from the JVM it'd be really hard to make that universal.
And it's pretty hard to argue for features Java can't use. Not impossible, e.g., invokedynamic, but certainly harder than if the next version of Java needed them.
The other biggie is that there's a hell of a lot of existing Java code out there, which could really benefit from the readability certain proposals offered. Rewriting in another language is impractical, but incremental improvements are not.
Re-write the VM
Java, the language, is beautifully designed. However, it's the implementation that's got the problem.
The Flash platform had grown yet the core engine is as slick as it was as if it never grew.
Challenge to Sun (or Oracle, I should say): Make a possibility for Java VM with a Java application to be packed in a single EXE, like how we are able to do standalone Flash applications.
Java (language) is not "dying", it just becomes stable
Have you ever heard someone say that C is dying because it tries not to adopt to the latest programming fashion? The whole discussion on the inclusion of everyones pet feature in the core language (not in some API) is ridiculous and demonstrates how far many of those bloggers are from reality. It is not the language, it is the ecosystem! For the ecosystem to thrive the core piece, the language, has to be predictable.
If some people feel the mood to program functional lately, there is Groovy or Scala to do this. Even a Lisp dialect is available. We can easily observe how widely those languages get adopted and where the real world problems arise, without spoiling Java with such experiments.
Post new comment