Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Debate: Should the Java language stop adding new features?

Debate: Should the Java language stop adding new features?


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?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Java feature set

    by Karl Traunmüller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The one thing that really puzzles me is: why is everbody insisting that Java needs/requires backwards compatibility? I don't think backwards compatibility should be maintained at all costs. To me, the goal should be to design a language that's tight (i.e. readable), elegant, and efficient (in terms of productivity).

    In my opinion, Microsoft did the right thing when designing .NET 2.0 - abandon backwards compatibility in favor of implementing new features completely and correctly. They were consistent enough to "drill out" the type system and runtime. Consequently, C# generics just work the way you would expect them to. C# 2.0 just feels very natural.

    In constrast, Java generics are basically useless - for all but the most trivial cases, you're stuck with compiler warnings, lots of artificial casts, or you simply can't do things the way you wanted to. Generics are a great thing if you can actually use them. In C#, you can. In Java, you can't.

    I don't understand why Java generics have been implemented that naively. Everybody should have realized that type erasure won't do the job. So I don't take the argument that in order to "not let a disaster like generics happen again, we won't add any new features to Java".

    I would strongly advocate adding some missing features to Java, and implementing others (i.e., generics) correctly. Java is a rather primitive programming language. Yet I fear that Sun won't ever take that route.

    Karl Traunmueller

  • More missing features

    by Karl Traunmüller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Another thing that comes to mind is the type system. Take numbers for example.

    In Java, you can't directly assign an Integer to a Long, which is what you would naturally expect to work. Integer and Long derive from Number, but there's no way of smooth conversion between numbers (aside from the artificial intValue/longValue).
    In C#, you have conversion operators (and operator overloading in general, which Java doesn't offer), and the compiler can convert between number types in a very natural way.


  • Re: Java feature set

    by Michael Neale,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes to me its not so much adding features as fixing things and implementing things that SHOULD have been there from the word go. If that means some cost of backward syntax compatability, so be it. Other suggest leaving it and "moving on" to a "main" language for the VM (eg scala) which would also be fine if enough people want to do it too (as it achieves the same end). But the VM and the language still have branding association, so it would seem a shame not to fix up the "flagship" language.

  • Other languages

    by Steven Devijver,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Java is a statically typed language without meta-programming features. If it's not in the byte-code it doesn't exists.

    The JVM can support meta-programming on existing byte-code and duck typing, see Groovy.

    There's probably an opportunity to create a version of Java that breaks backward compatibility on the byte-code level (for example, adding methods to java.util.Collection) but this will be a language separate from Java.

    Since we already have those - Groovy, Scala - it seems that those that limit themselves to the Java language will have to accepts its idiosyncrasies. However, those same people can combine Java with other languages on the JVM: Groovy, JRuby, Scala, ...

    Maybe it's time to give up this fetish with the Java language and embrace the richness of the Java Platform.

  • Re: Other languages

    by Emil Vladev,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Maybe it's time to give up this fetish with the Java language and embrace the richness of the Java Platform.

    Very well said. The JVM has a lot of future, but I'm unsure about the Java language. There are far expressive languages today, that can be ported to the JVM. I would suggest to everyone to have a look at the Io programming language - it's very, very promissing.


  • IT's Centre of Gravity has Moved to XML; Java Needs Native XML Support

    by Ganesh Prasad,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Java must support XML as a first class datatype, and not just with clumsy libraries like JAXB (patience, no flames, please!). We need a "java.lang.XML" datatype, so that we can do in Java what we can do, for example, in JavaScript with E4X.

    With increased SOA thinking (whether SOAP or REST), there is more emphasis on XML as a language to abstract and represent the interface to encapsulated domains, more emphasis on XML as a data interchange language between such autonomous domains. Java has now hunkered down to be more of an implementation language _within_ a domain, and in a SOA world, it needs to be able to handle its interactions with other domains better, i.e., it needs to handle XML much more elegantly and naturally.

    Contrast the elegance of this E4X example (which "mashes up" two XML documents) with anything currently possible in Java, and you'll see what I mean:



    <META http-equiv="Content-Type" content="text/html; charset=UTF-8">

    <title>Mashup Demo (Pure content aggregation)</title>





    Grocery list with items and quantities only (e.g., my shopping list)


    var gList = new XML();



    <line-item prodid="tomato" qty="4"/>

    <line-item prodid="potato" qty="3"/>

    <line-item prodid="onion" qty="6"/>

    <line-item prodid="chilli" qty="40"/>



    alert ( "Raw shopping list\n\n" + gList );


    Grocery unit prices (e.g., supermarket prices)


    var gPrices = new XML();



    <prod id="potato" unit-price="10.00"/>

    <prod id="tomato" unit-price="20.00"/>

    <prod id="onion" unit-price="30.00"/>

    <prod id="beans" unit-price="40.00"/>

    <prod id="chilli" unit-price="0.50"/>



    alert ( "Grocery prices\n\n" + gPrices );


    Mash up the two pieces of content to produce an augmented grocery list with
    individual costs and total cost


    var total = 0.0;

    for each ( i in gList.descendants("line-item") )


    i.@amount = i.@qty *["@unit-price"];

    total += Number( i.@amount );


    gList..list["total-amt"] = total;


    Display the mashed-up list


    alert( "Mashed-up shopping list\n\n" + gList );



    Copy and paste this example into an HTML file and view it in your browser. You'll see what Java needs to become.

    Already, there is a movement towards languages that make XML manipulation simpler. WSO2's Mashup Server uses JavaScript as its implementation language. The Glassfish server enables server-side JavaScript through its Phobos module, which shows the inroads JavaScript is making into Java territory. PHP supports E4X-style XML manipulation through SimpleXML. Groovy and Ruby have similar capability. So what ails the compiled languages?

    I've blogged about this here and here. Sure, Java can stop adding features, but not before it supports XML natively.

    My two cents.
    Ganesh Prasad

  • Re: IT's Centre of Gravity has Moved to XML; Java Needs Native XML Support

    by Ganesh Prasad,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BTW, that example only works in Firefox because of its native E4X support. Apologies to IE users.


  • Power to Weight ratio

    by Gili T.,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I like Joshua Bloch's argument best: there is nothing wrong with adding new features so long as they have a good power-to-weight ratio.

    There is no need to freeze Java's features. Nor is there need to stuff the entire kitchen sink into it.

  • Clean up the house!

    by Robert Hicks,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Deprecate some stuff. Put them in jar files that you can include if you still need it. Make Java more modular. Fix what is already broken and smooth out as many warts as you can. Focus on ringing the last ounce of speed out of the VM. Enhance the VM mechanism (multiple loads, better for others to plug into).

  • Very good points.

    by Nos Doughty,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is a critical discussion which will clearly have ramifications for the software development industry far outside of the current context of Sun and Java.

    1) Backward compatibility serves Microsoft well enough for them to suffer (or is it inflict upon it's users?) the inevitable problems which come with it for one very good reason. They are currently a virtual monopoly in the desktop OS and productivity suites market - and if they break backwards compatibility and are forced to compete with themselves they will open the market to other competitors. Is that the case for Sun? No, they are competing in a very aggressive market again (at least) DotNet and RoR (if not LAMP and others). I think that Sun is insane to place such a high premium on backwards compatibility in such a competitive market when the other options will start to look better and better over time. This is why MSoft is so happy to forgo backwards compatibility with DotNet but not with Windows or Office.

    2) Clearly generics are a disgrace. I have made it a point to use them correctly as best as I can understand them and am continually surprised by them. I remember the STL in the 0.2, 0.3 days and it reminds me of that (but with much better error messages!). Still people are missing a point about it. It wasn't backwards compatibility with the Java language that limited the design, it was backwards compatibility with the JVM itself, which is a whole other kettle of fish! Would it have been worth it? Maybe. Msoft seems to version the DotNet runtime separately from the language and it doesn't seem to bother them. But generics (unlike closures but similar to continuations) are a much bigger change than any other as the whole platform needs to evolve.

    3) I fear that Scala is just too complex for the masses (due to it's functional programming roots). Although I understand what I see with Scala, I just can't think of solutions to problems in a way which leverages it's power - a problem which simple closures in Ruby and Groovy do not suffer from. I think Scala should be officially 'adopted' by Sun like JRuby (same with Groovy actually), but I think it's a mistake to push something so advanced as the mainstream approach.

    4) Having said that, of all the changes ever proposed for Java - a full closure proposal - one which would allow creation of new 'control statements' would be for me the single best change that could be made. Closures are a HUGE way to improve the quality of the coding. With a single change - although closures themselves may be hard to write (like generic classes) the senior developers on projects can make such plain abstractions for the access to the resources that the others need that code will be free of the badly handled exception/finally and synchronized blocks. It's HUGE! I don't care if it is in Java 7 (or lets say Java 1.7) or a new and shiny Java 2.0 - but I want it!


  • Re: Java feature set

    by Casper Bang,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with Karl, I think he hit the nail with his post. Think of it this way: What if you had an application you started writing 15 years ago, filled with workarounds and hard coded stuff which just screams for not only refactoring but a genuine redesign. It's extremely complicated and it can no longer take more requirement changes - it's unmaintainable. Most will not see this scenario progress, it will have to be, at least partly, redesigned one way or another. Now why shouldn't this also be the case with a programming language? It's also just software!

  • Add the features

    by Robert Dean,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Those who advocate freezing language evolution in favor of going to something new are missing the point.

    The only reason to "stabilize" a language is if it is so hopelessly foregone that new essential features cannot be added in an intelligent way to the language. There is nothing inherently difficult about the Java syntax that would prevent new features from being added.

  • Re: Java feature set

    by Hendry Luk,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What backward compatibility?
    C# did NOT break any backward compatibility when they introduced generics in C#2.0. You can run your old bytecode written on .Net1.0(and 1.1) DIRECTLY on .net2.0 without any recompiling or any modification. Microsoft solved this backward compatiblity issue by keeping both their generics and non-generics versions of all the classes in their SDK (i.e. they have both Dictionary and Dictionary<T,Y>). So the new .Net2.0 framework will still be able to run all your old non-generics .net1.0 libraries just fine.

    When Java talked about "backward" compatibility, they were actually talking about "forward" compatibility. They were talking about guaranteeing that the old Java4 will be able to run the newer applications written on Java5. Silly. Silly silly goal. Even sillier, considering that in practice you normally won't be able to run your new java5-targetting-applications on java4 anyway.</t,y>

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p