Recently, there has been a lot of debate over the future of the Java platform, with some arguing for more features to compete with languages such as C# and Ruby, and others saying that Java should become a more stable language lest it become too complicated to use. Bruce Eckel started a new round of debates by stating that Java should stop adding new features entirely.
In his blog post, Bruce Eckel said that Java needed to stop evolving if it is to stay in the mainstream, and that it is already "too noisy" as a language, with code being unnecessarily verbose (e.g. System.out.println()). Eckel identified Java generics as an area in which the complexity added has caused concern, and also described what he sees as a key problem with Java:
The only control we have over complexity is abstraction: hide the parts that don't matter ("divide and conquer" is a variation). The paradox of of Java is that a critical aspect of the complexity problem was ignored; code readability was not considered an important issue. It seems that if the IDE writes the code for you, then it doesn't matter if that code is needlessly complex.
[Joshua Bloch] took this idea of complexity one step further. He said that it's not just the complexity of a particular feature in isolation, where it can often seem fairly straightforward. It's the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. When you shoehorn a feature into an existing language rather than carefully designing it in from the beginning, you cannot control how that feature combines with other existing features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it's too late to do anything about it. Over breakfast Josh noted that this kind of complexity makes for a bountiful supply of Java puzzlers; entertaining for him but not good for the community as a whole.
Eckel identified himself as a "feature junkie" who had always thought of language evolution in terms of new features, but now questions whether a feature should be skipped if it can't be implemented correctly (as with Java's generics). Eckel noted that both C and C++ are very stable, and mentioned that Java should stabilize as well rather than chasing after new language features or otherwise trying to follow every market impulse. The idea of breaking backwards compatibility was also raised, with the opinion that those who want the old features can stay with the old version and not upgrade to the new Java. Eckel also warned against the perils of maintaining backwards compatibility at all costs:
If we can't insert features correctly because of backward incompatibility, we are straightjacketed when it comes to language changes; we are in the same position as C++. C++ is often criticized because of its design, but I was on the standards committee for 8 years starting at its inception, and I saw all the debate around each language feature. These were not made capriciously, but very carefully and thoughtfully. What produced the complexity and difficulty of the resulting language was one thing: backwards compatibility with C. Once you bind yourself to backwards compatibility with anything, you must be prepared for your language to be corrupted as you add features. If Java is unwilling to break backwards compatibility, then it is inevitable that it will acquire both unproductive complexity and incomplete implementation of new features.
Eckel described new languages as the correct place for fundamental new features, and said that Scala was "the current best exit strategy for Java". He also stated that Java's only salvation would be to become a workhorse like C and that only cleanup and fleshing out of incomplete libraries should be done in the future, with major language changes like closures being left to other languages rather than being bolted onto Java.
Kevin Dangoor agreed with Eckel, saying that adding new features to a language which requires backwards compatibility will be clumsy at best, and pointing out that ECMAScript has the same problems as Java has in this realm. Dangoor also questioned the criticism that developers are always looking for new, shiny features to help with projects:
Software is the stuff of thoughts. It’s very malleable and new ideas can be tested out fairly cheaply. With the internet, new ideas and code can spread far and wide quickly. This is all a good thing. For me, creating software today is tremendously better than it was 5, 10, 15, 20 years ago. I watch many of the shiny things go flying by, but I don’t actually use them. But I consider the shiny things to be very important. There are all kinds of ideas wrapped up in there that can be applied in different contexts and with different tools. Some of the implementations that come out of those ideas will make it into the mainstream.
Generally speaking, people don’t switch to all of the shiny things that fly by. Some people will give them an honest try and will either be rewarded for being a successful early adopter or will suffer some pain and head back to other solutions. If enough people like the idea and follow through, it will become mainstream. Rails was the shiny new thing in 2004. There were undoubtedly people who felt the pain of being early adopters, but many more were far more productive than people using other tools that were common back in those days. Regardless of how many people ultimately adopt Rails, the fact is that many of the ideas presented there have had a significant influence on work that has happened since.
Cay Horstmann also chimed in, saying that there needs to be less focus on the syntax of Java, and more focus on the pain points. Horstmann also referred to C++ and said that Java addressed the two major pain points it had, which were memory management and GUI/database access. However, Java now has it's own pain points which need to be addressed:
- Boilerplate code - getters and setters, event listeners written as anonymous classes, and long type declarations which could be inferred by the compiler
- Web application development - this is difficult, and developing web applications with complex and underpowered technologies like JSP and JSF "is like eating soup with a fork"
- Concurrency - "I am not smart enough to write a nontrivial concurrent program where I can say with confidence that it won't ever deadlock and that it won't have any race conditions. Just like I was not smart enough to write a nontrivial C++ program where I could say with confidence that it won't ever leak or corrupt memory"
Some other opinions:
- Phillip Calçado agreed that Java should be fixed rather than expanded, but disagreed that Java is inherently difficult to read saying that Java was more readable than languages which existed when it was created like C++
- Richard Relos said that most Java code doesn't use new language features anyways, and that adding more new features just dilutes developer attention and logic formulation
- Ian Cooper saw parallels with C#, and questioned whether it too is reaching the point of diminishing returns while agreeing that the place for major new features was a new language
- Giovani Salvador voiced concern that if features are no longer added to Java that it will become obsolete, and that Java developers will become "dinosaurs"
What do you think?