Skip to main content

Freeze Java?

Posted by robogeek on January 10, 2008 at 12:31 PM PST

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.

Related Topics >>

Comments

Bruce Eckel is right IMHO. Java started as the language, that made developement easier (compared to C / C++). This is not true anymore. Every change to Java was more or less a change which brought more complexity. Features like generics or autoboxing are only useful, when the overall complexity of code can be reduced and the developer can concentrate on the problem space instead of dealing with language shortcomings. Compare this to something like LINQ in the DotNet world. As much as I don't like MS, their direction to make things easier and more uniform for the developer where appropriate - even if it means sacrificing backward compatiblilty - will pay off. Or have a look at OSGi, which has solved the versioning* and modularity problem for Java for some time know and it is still not adopted by Sun (probably for the simple reason that they don't have invented it themselves - they'd rather propose new, untested ways of doing more or less the same). And instead of fixing problems, more features are bolted on top of Java. Without drastic changes, Java is on the path to become the Cobol of the 21st century. -- *) @Mikael Grev Have a look at http://www.osgi.org Their way of dealing with version compatibilty is IHMO much better. If we have to deal with it at the code level like this, we've lost.

I agree with mikeazzi regarding Eckel. David's assertion that the "big value of the Java ecosystem is the existing stuff" bothers me. I'd say it's the opposite...the existing stuff (frameworks that use xml for example) is causing problems for Java. And the generics gripes...just don't use them if you cannot understand them. Is there some evil entity forcing people to use them when they don't want to? Is their mere existence upsetting to people who demand that they master every possible nuance of a computer language? If that's the case you'll be disapointed with AS3, Ruby, or JavaScript. Metaprogramming is mysterious and has more potential for obvuscated wizardry than Java every did.

@ mystermask
OSGi is a much much more complete solution, but it is also much much heavier. We hould have both (and will have, at least a Java version of OSGi).

The Compatibility is for solving simpler things i an easy and optional way. It would be like formalizing all those command line switches but doing them in a bunch. The API was just a suggestion though, it can be bettered in many many ways.

Seems like what you want is something like I proposed here: http://www.javalobby.org/java/forums/t88549.html

I can not understand why you have not created a solution like this. For instance this bug would be super simple ti fix with such an API: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5035820

There is no need to rethink the whole language the BGGA way, what we need are some smaller adjustments like Josh's CISE, ARM blocks and a better properties/JavaBean spec. And of course the Compatibility API. :)

Cheers,
Mikael Grev

+1 for Mikael Grev's Compatibility API!

Don't freeze Java, but don't add to it either. Java does not need to gain complexity or new features, it needs to lose some! Reduction is a valid and sometimes more appropriate path for evolution, and Java and its ecosystem are overdue to walk it.

The only way for OSS to effect dramatic change contrary to a project's primary sponsor is to fork. Would a fork of Java be terrible? It worked for gcc. But it always remains a possibility no matter what Sun decides. Personally, I think generics were brilliant and the best thing to happen to Java since 1.0. *Any* feature that moves errors from runtime to compile time gets gold stars in my book. For the same reason, I see autoboxing as the biggest blunder since 1.0... it moves many errors from compile time to runtime, and I sure hope we get a switch to turn it off in javac soon.

> Java is OSS now. Lets community decides what is the future for Java.

Oh no! That would be a really bad choice. Design by committee is a well known dead end. http://en.wikipedia.org/wiki/Design_by_committee

@linuxhippy: Interesting point -- and maybe growth and change of the language is unimportant so long as the core libraries (java.* and javax.*) are growing and changing. At the same time there is clamoring in the community for various changes. That clamor indicates at least some people want further changes to the language. The Posse raised an interesting pair of points - On the one hand that there are multiple languages running on the JVM allows for language experimentation to take place in other languages and still take part in the java ecosystem - on the other hand, tooling and integration with IDE's is important, and having language changes interferes with strong tooling and integration with IDE's unless you make sure to do tool/integration development concurrent with language changes.

The Java language was basically "frozen" between 1.1 and 1.4 and I really liked the stability of the language. With Java5 the bad done generics came and a few other additions like (ugly!) autoboxing - done in an ugly fashion to work arround needed JVM changes. Was Java dead between 1.1 and 1.4? I don't think so. lg Clemens

Are everybody is crazy at Sun? I am seeing many articles that associate Java with bad words such as dinosaur, dead, etc. Who cares what Bruce says. He is paid to say that. There are millions of people around the world. Their opinion is more important! Would all shut up and don't associate Java with those words? Don't you know anything about psychology? Java is OSS now. Lets community decides what is the future for Java.

I don't understand why the double standards. Why Microsoft can stick every single feature they can find as fast as they can with a complete disregard for what their users think and everytime Sun thinks about doing anything there's someone like Bruce Eckel, who thinks C# is excellent because of the changes, saying not to? Why in Java it is bad and in .Net it is not?

For what I have read about this guy he likes to bash generics in Java as some sort of attempt of "copying C#", but that was intended to be included much before C#'s. And besides what he doesn't seem to like are some implementation details that don't really change anything in the life of the developers.

I think what they would like is to deprecate Java altogether so the language #put their favorite language here# can have a chance because the market would naturally look for something new.

A total freeze would be as big a mistake as a frenzy inclusion of every techie vogue. There are very good proposals for simplification of the language. A very good was made, I think, from the Brazilian JUG. Things like these show up from prolonged practical experience of using the language in real projects. This has to be possible. I think what completely went wrong, where the all those proposals to include every thinkable feature from several scripting languages. There was no week without a new one. This made me really nervous. A language that is as widely used as Java must have a stable core mainly the APIs should evolve. With respect to closures I think the main problem is the overly complex BGGA proposal. I think the simplification of the usage of inner classes as in the CISE that is good for 90% of the use cases is more appropriate.

May I remind you that our friend Bruce Eckel here has got his little own ax to grind in the form of Flex. He has been on this Flex bandwagon for a while now. So I would take his advice on what's good for Java with a little grain of salt as his business interests don't necessarily go hand in hand with Java's. Let me ask you this as an analogy: If someone at Microsoft came out and said the same things that Bruce did, how much value would you have given those claims. Same deal here with Bruce I would say.

(with "you" above I mean Sun)