Tags: Java
The latest
Javaposse podcast (Java Posse #158 - Newscast for Jan 9th 2008) is out and has some interesting discussion of a question posed by Bruce Eckel (Java: Evolutionary Dead End). Bruce's title is a little misleading because he's not claiming Java is Dead.. but that some things have been done to the Java language to add unnecessary featuritis some of which are evolutionary dead ends. The suggestion is to freeze the Java language ... and to do language experimentation using other languages that run on top of the JVM.
I'm generally agreeable with this.. I think the moves we've made to make for stronger support of other languages on the JVM is brilliant. I think the important thing is the platform, and really the virtual machine and the ecosystem of existing libraries that run on this platform. That fabled 'network effect' is helping us here.
But 'freeze' the Java language? Hmm.. unsure about that. The language changes which have been made have a poor history of causing adoption problems. But I think it's quite possible to add features to a language where they slide in and feel like a natural part of the langauge. I don't think, as Bruce suggests, that the only time to do language design is at the very beginning of a new language. I do think the early years of a language is critical to forming the language, but that to freeze any changes later may be a mistake. In general I think that frozen things, things which cannot change, are in an inevitable death spiral and that 'life' always means the ability to change and grow.
A couple thoughts I have are:-
Other languages running on the JVM ought to do a good job of integrating with existing Java classes.. the big value of the Java ecosystem is the existing stuff, and that's the big value the JVM offers to a language designer.
Changes to the Java language could be coupled with tools that help to convert source code to the new language features. This could especially make use of the compiler API that is now available and/or the jackpot tooling that is now in Netbeans. I think one of the issues making previous language changes difficult is the existing body of source code, and that if tools existed which robustly and simply made code changes then the migration ought to be easier.
Bruce made an interesting point about compatibility -- as a former member of the CCC team here inside Java SE engineering, I had a few years experience reviewing and approving platform changes. So, heck, compatibility when taken to the extreme we've taken it is really a double edged thingymajob isn't it? It provides some of the value to the Java ecosystem, that theoretically (absent bugs) you can take Java class files compiled in the stone age and still run them today. But it also provides resistance to fixing bugs or adding features, in some cases. This kind of compatibility may well be a heavy weight that over time interferes with the necessary change required to keep the Java ecosystem a living and breathing entity.
But this compatibility requirement goes beyond the language. It includes the runtime libraries of the core classes (java.* and javax.*) and behavior and signatures of the classes and methods therein. Even other languages running on the JVM are affected by binary compatibility requirements.
Hurm.. it occurs to me off the top of my head that a conversion tool could help here as well. Say for Java 8 the goal were to remove all deprecated methods and a few other changes. It could be declared that class file version n corresponds with that change. The JVM could then recognize "oh that's an old class file" and do something automatic like pull in a compatibility library, or do byte code transformations that changes the class files before execution, etc.
In any case the core thing I want to say is one general principle I understand is that things which cannot change are in a death pattern, and things which can change are in a living pattern. Which tells me that to suggest freezing a thing (the Java language) means to say this thing (the Java language) needs to die.
Source:
weblogs.java.net
