This post originated from an RSS feed registered with Java Buzz
by Geoffrey Wiseman.
Original Post: Java: Balancing Evolution with Stability
Feed Title: Furious Purpose
Feed URL: http://www.jroller.com/diathesis/feed/entries/rss
Feed Description: Thoughts and experiences on technology and software.
Ed Burnette and
Mark Watson
recently raised the issue of whether Java should evolve or stabilize, while I can't disagree with all of
the points they make, neither can I fully agree.
Stability
As Mark and Ed point out, there are costs to adding new language features: the various JVM vendors have to catch up,
revising their JVM implementations. This can cause cross-platform problems wherein Apple's JVM takes a while to catch up;
cross-vendor problems, wherein JRockit or Harmony don't support the features that Sun's VM supports. This can reduce the
ease of spreading the Java platform as far and wide as we might like.
Evolution
If Java stays entirely still, adds no language features, this has a cost as well. Other languages will not stay still:
they will innovate, and evolve. New languages will arrive and seek dominance through their language features. The Java
platform, under the constant assault of attempts to improve upon it, will fade and stagnate. It won't die, but it will
become COBOL, a language in which enterprise systems are maintained, rather than developed. We might as well elect
Computer Associates, experts at putting software projects out to pasture, to lead the JCP.
Even now, we're seeing some movement in Java developers who believe there's something to be gained from dynamic languages,
or from the rapid evolution of platforms likes Rails. We have problems that we need to address, and some of the solutions
may require new language features.
Balance
I don't think that we should rush out and add new features to Java with every point release (hi, C#), nor that we should hold
the line at 1.4, and never evolve the language (hi, Cobol). It's possibly even true that the Java language shouldn't be
the platform for innovation and experimentation; we can adopt successful features once they've passed the trials of time in
other, younger, more experimental languages. These might be rational approaches for a mature language. To be honest, I'm
fairly sure that I don't know how far to either end of the spectrum we should draw the line, but I believe that most of the
healthy alternatives lie somewhere in the middle. And, come to think of it, I think Sun's done a reasonable job of trying
to balance those two concerns, for the most part.
Realize that Java is a mature language with a wide array of implementors, growing by the year: in order to take advantage
of that strength, we need a certain amount of stability. But also realize that it's a living language, being used by real
people every day to solve their real problems, and if it becomes so stable that we believe that other languages are better
choices to solve their problems, then Java's strength becomes it's weakness. Seek a balance between these two that allows
for measured growth of the platform in a way that is not overly disruptive.
Previous Topic
