5 ms·

I think you are being very unfair to Java here. There are two very important issues to consider here. 1) One reason people like Java is reliability. Therefore

I think you are being very unfair to Java here. There are two very important issues to consider here. 1) One reason people like Java is reliability. Therefore adding Lambdas must not break any existing code at all. This includes no breaking changes to any part of the standard library. 2) As we can't make substantial changes to existing code, the lambdas we add have to fit well with existing code bases, without adding too many nasty corner cases to lambdas. 3) Once added, you can't ever make any changes to lambdas. This is a one-time opportunity. So you better get it exactly right, because you can't go back. You say it is "never urgent" to make existing Java users rewrite their code. It is not "never urgent", it is a fundamental pillar of Java that users will never have to rewrite their code, and that is one of the major reasons that Java is so popular with business. You can argue that Java shouldn't make that decision, and should end up with something like the long drawn-out slow change to Python 3, or the Perl 6, but it was a conscious choice, not just something the developers can't be bothered to do. Under those kinds of restrictions, I would argue adding lambdas to any system would be difficult. There were similar difficulties adding them to C++, and I would say in many ways Java is getting it better than C++ (but that is largely due to the much higher level of complexity of the C++ language).

raganwald 15y ago
Java is an artefact, not a person. It is not possible to be “unfair” to it, nor is it possible to be “fair” to it. What I describe is a process by which a series of good decisions over time lead to a result that is sub-optimal in one axis, namely velocity of progress. If you want to argue that this is optimal overall, even if it is less than optimal for the velocity of progress, I do not stand in your way. It is very similar to the “Innovator’s Dilemma,” where companies can make a series of perfectly logical decisions to maximize their profits and wind up missing a big new market that disrupts their existing market. I leave it to you to decide whether Java has missed a big new market for programmers by virtue of being trapped into serving its legacy customer base. The thing I see as similar is the cumulative effects of many small decisions over time.
- CJefferson 15y ago
  Your article appears to be written in various ways which imply Java is in a bad state. Consider: What is my client to think? That I have given them a marvellous, well-architected application? Or that years of bolting a feature on here and hacking a workaround there have created a nightmarish miss-mash where the velocity of progress is asymptotically approaching zero? While not directly applying to Java, I feel the implication here is that Java is in the second category. However, the comparison with Java breaks down. I am sure the Java designers could have cleanly added lambdas in a very short period of time, and all other kinds of exciting features, if they abandoned backwards compatibility. There is a huge difference between modifying an app and a language in use by millions of programmers. There is an interesting discussion to be had an apps become a "nightmarish mish-mash", and on languages becoming parallelised by backwards compatibility, but I am not sure they are as directly comparable as you wish. However of course, each to their own opinion.
- mnutt 15y ago
  It's interesting to consider Java in light of the Innovator's Dilemma, since companies facing the Innovator's Dilemma would like to avoid it so they can continue making money. But Java is a tool more than it is a company, so maybe it is actually good that it maintain its course, even if it means its gradual irrelevance for many of the tasks it was once suited for.
  - cpeterso 15y ago
    The separation of Java the language from Java the virtual machine might allow Sun/Oracle avoid the Innovator's Dilemma. They can maintain Java as a conservative language, the "COBOL of the 21st Century", but innovate with new (but conveniently binary-compatible) languages like Scala and Clojure.
- stmartin 15y ago
  raganwald, I am waiting for your language that will, across a 10+ year time span with millions of users/contributors, not only serve its legacy but also adapt to/conquer new markets. Just make sure you don't call it LISP2 or Arc2.
dasil003 15y ago
Is Java just a vehicle for a colorful metaphor about code rot?
matan_a 15y ago
I think one of the biggest issues with this whole thing is the time-to-market. Lambdas are planned as part of Java 8. At the moment, that's in about a year from now. Then consider when you'll actually upgrade your production code to use Java 8...I have a feel that by the time you see some stable lambda code in production (depending on how bleeding-edge you are), it will be quite a while. Who knows by then how things will be. You might even be coding in Scala or Clojure...
stevelosh 15y ago
> It is not "never urgent", it is a fundamental pillar of Java that users will never have to rewrite their code, and that is one of the major reasons that Java is so popular with business. During my (admittedly short) time at a Java shop we were running all of our stuff on Java X, where X was at least 2 versions less than the currently released version. The newer versions had some nice features that would have been great to use, but we never upgraded for fear of breaking something. I got the hell out of Java-land as soon as I could, so I don't really know whether people were justifiably afraid or just overly paranoid, but either way this seems to be at odds with the "fundamental pillar" you mentioned. My experience could very well have been an uncommon outlier though. EDIT: Fixing formatting. I wish HN used Markdown or something instead of its own unique snowflake of a markup format.
- angelbob 15y ago
  I share your experience. We had to do a huge amount of maintenance to upgrade from Java 5 to Java 6. It was definitely not just drop-in. Does that mean the code was written badly? Possibly. It wasn't amazing. Still, that seems more like the rule than the exception.
  - InclinedPlane 15y ago
    It shouldn't matter how well the code was written. Binary compatibility should be binary compatibility, period. If it compiles it should be compatible across JVMs. The fact that this is not the case is just another nail in the coffin.
  - lemming 15y ago
    I'd be interested to know what problems you had. We literally dropped Java 6 into our million line project without problems. Despite what the OP implies, this was huge for us. If Java were maintained like, say, Rails we'd still be on 1.3.
    - haldean 15y ago
      I'd like to know as well -- my team (~1MLOC Java product) upgraded from Java 5 to Java 6, and then Java 6 to Java 7, by changing a line in our build script, and everything worked fine.
jbellis 15y ago
Right. For the JDK developers, the First Commandment is, "Thou shalt not break existing code, ever." Almost all of the things people dislike about post-1.1 Java stems from that, especially the non-reified generics. It's valid to say "I think they should value some things higher than backwards compatibility." It's not valid to say "they're idiots for doing it this way." (Which I don't see in this article, but I see in plenty others.)
fleitz 15y ago
It's not unfair to java at all, C# has had all these features for years despite being pretty much the same language. With C# you have two options, keep compiling your code with the old compiler, or fix your code and compile it with the new compiler. I bet there will be a standardized and working version of lambdas in C++ before Java, so I'm not sure what the big deal with backwards compat is.
- zokier 15y ago
  C++ has lambdas now. C++11 is approved and published as ISO/IEC 14882:2011(E) standard recently. Lambda part of that standard is implemented in icc, gcc and msvc. But the difference is that C++ has relatively minimalistic runtime compared to JVM, so it is not nearly as fragile. Also lambdas for C++ have been under work for a very long time. The first version of proposal to add them to C++0x is from 2006 (as far as I can tell) and it refers to papers dating back to 1988 which discuss adding "Lexical closures" to C++. So based on that, C++ committee used over 5 years to get lambdas on a release from a proposal. 2-3 years for Java doesn't sound that bad after all.
subwindow 15y ago
Backwards compatibility is great and all, but at what cost? One of the main reasons why Windows eventually started to collapse under its own weight was backwards compatibility. If a piece of software is so tied to backwards compatibility that it cannot change it will, necessarily, die. That said, statements like "Once added, you can't ever make any changes to lambdas" are obviously bullshit. Programming languages can and do successfully undergo significant changes. Ruby 1.9.2 is a completely different beast than 1.8.0 (including significant changes to lambda sytax), and I'd expect there are few (if any) applications that could be upgraded without significant changes. The same could be said for PHP 4 -> PHP 5, Perl 5 -> Perl 6, and Python 2 -> 3. Contrast those languages to Java, which is largely the same since 2001. Sure, there's a cost to everybody when you have to upgrade your app, but there's a much greater benefit when it is all said and done.
- angelbob 15y ago
  Ruby breaks these things. But Ruby is not generally even considered for a lot of what Java is used for. Those two things aren't independent. Don't get me wrong, I like Ruby far better than Java. But Ruby is simply not considered a stable enough language for your huge app that you plan to maintain for 20+ years... Nor should it be. Java is that stable. On the flip side, Ruby is improving much more quickly than Java. I write small apps I plan to maintain frequently far more often than I write apps that need to sail onward for 20+ years. Two different market niches, defined by two different groups of customers.
- statictype 15y ago
  One of the main reasons why Windows eventually started to collapse under its own weight was backwards compatibility. True. On the other hand, that backwards compatibility is an important reason why Windows was so utterly dominant for so long. It's (as always) a tradeoff.
eneveu 15y ago
Brian Goetz's talk on Virtual Extension Methods at the JVM Language Summit 2011 was pretty interesting in this regard: http://medianetwork.oracle.com/media/show/16999 http://medianetwork.oracle.com/media/show/16999 He explains why adding lambdas isn't that straightforward, due to backward compatibility, but also because it wouldn't make sense to add lambdas without updating the standard APIs to benefit from these lambdas. Some of these APIs, such as the collections framework, are interface-based. Adding methods to an interface would break backward compatibility, which led them to Virtual Extension Methods. For example, we could add a forEach method to the Collection interface without breaking backward compatibility: interface Collection<T> { // existing methods void forEach(Block<T> block) default Collections.<T>forEach; } When not overriden, this virtual extension method would default to calling a static method, Collections.forEach(Collection<T>, Block<T>), thus preserving backward compatibility.

raganwald 15y ago

Java is an artefact, not a person. It is not possible to be “unfair” to it, nor is it possible to be “fair” to it. What I describe is a process by which a series of good decisions over time lead to a result that is sub-optimal in one axis, namely velocity of progress. If you want to argue that this is optimal overall, even if it is less than optimal for the velocity of progress, I do not stand in your way. It is very similar to the “Innovator’s Dilemma,” where companies can make a series of perfectly logical decisions to maximize their profits and wind up missing a big new market that disrupts their existing market. I leave it to you to decide whether Java has missed a big new market for programmers by virtue of being trapped into serving its legacy customer base. The thing I see as similar is the cumulative effects of many small decisions over time.

CJefferson 15y ago
Your article appears to be written in various ways which imply Java is in a bad state. Consider: What is my client to think? That I have given them a marvellous, well-architected application? Or that years of bolting a feature on here and hacking a workaround there have created a nightmarish miss-mash where the velocity of progress is asymptotically approaching zero? While not directly applying to Java, I feel the implication here is that Java is in the second category. However, the comparison with Java breaks down. I am sure the Java designers could have cleanly added lambdas in a very short period of time, and all other kinds of exciting features, if they abandoned backwards compatibility. There is a huge difference between modifying an app and a language in use by millions of programmers. There is an interesting discussion to be had an apps become a "nightmarish mish-mash", and on languages becoming parallelised by backwards compatibility, but I am not sure they are as directly comparable as you wish. However of course, each to their own opinion.
mnutt 15y ago
It's interesting to consider Java in light of the Innovator's Dilemma, since companies facing the Innovator's Dilemma would like to avoid it so they can continue making money. But Java is a tool more than it is a company, so maybe it is actually good that it maintain its course, even if it means its gradual irrelevance for many of the tasks it was once suited for.
- cpeterso 15y ago
  The separation of Java the language from Java the virtual machine might allow Sun/Oracle avoid the Innovator's Dilemma. They can maintain Java as a conservative language, the "COBOL of the 21st Century", but innovate with new (but conveniently binary-compatible) languages like Scala and Clojure.
stmartin 15y ago
raganwald, I am waiting for your language that will, across a 10+ year time span with millions of users/contributors, not only serve its legacy but also adapt to/conquer new markets. Just make sure you don't call it LISP2 or Arc2.

dasil003 15y ago

Is Java just a vehicle for a colorful metaphor about code rot?

matan_a 15y ago

I think one of the biggest issues with this whole thing is the time-to-market. Lambdas are planned as part of Java 8. At the moment, that's in about a year from now. Then consider when you'll actually upgrade your production code to use Java 8...I have a feel that by the time you see some stable lambda code in production (depending on how bleeding-edge you are), it will be quite a while. Who knows by then how things will be. You might even be coding in Scala or Clojure...

stevelosh 15y ago

> It is not "never urgent", it is a fundamental pillar of Java that users will never have to rewrite their code, and that is one of the major reasons that Java is so popular with business. During my (admittedly short) time at a Java shop we were running all of our stuff on Java X, where X was at least 2 versions less than the currently released version. The newer versions had some nice features that would have been great to use, but we never upgraded for fear of breaking something. I got the hell out of Java-land as soon as I could, so I don't really know whether people were justifiably afraid or just overly paranoid, but either way this seems to be at odds with the "fundamental pillar" you mentioned. My experience could very well have been an uncommon outlier though. EDIT: Fixing formatting. I wish HN used Markdown or something instead of its own unique snowflake of a markup format.

angelbob 15y ago
I share your experience. We had to do a huge amount of maintenance to upgrade from Java 5 to Java 6. It was definitely not just drop-in. Does that mean the code was written badly? Possibly. It wasn't amazing. Still, that seems more like the rule than the exception.
- InclinedPlane 15y ago
  It shouldn't matter how well the code was written. Binary compatibility should be binary compatibility, period. If it compiles it should be compatible across JVMs. The fact that this is not the case is just another nail in the coffin.
- lemming 15y ago
  I'd be interested to know what problems you had. We literally dropped Java 6 into our million line project without problems. Despite what the OP implies, this was huge for us. If Java were maintained like, say, Rails we'd still be on 1.3.
  - haldean 15y ago
    I'd like to know as well -- my team (~1MLOC Java product) upgraded from Java 5 to Java 6, and then Java 6 to Java 7, by changing a line in our build script, and everything worked fine.

jbellis 15y ago

Right. For the JDK developers, the First Commandment is, "Thou shalt not break existing code, ever." Almost all of the things people dislike about post-1.1 Java stems from that, especially the non-reified generics. It's valid to say "I think they should value some things higher than backwards compatibility." It's not valid to say "they're idiots for doing it this way." (Which I don't see in this article, but I see in plenty others.)

fleitz 15y ago

It's not unfair to java at all, C# has had all these features for years despite being pretty much the same language. With C# you have two options, keep compiling your code with the old compiler, or fix your code and compile it with the new compiler. I bet there will be a standardized and working version of lambdas in C++ before Java, so I'm not sure what the big deal with backwards compat is.

zokier 15y ago
C++ has lambdas now. C++11 is approved and published as ISO/IEC 14882:2011(E) standard recently. Lambda part of that standard is implemented in icc, gcc and msvc. But the difference is that C++ has relatively minimalistic runtime compared to JVM, so it is not nearly as fragile. Also lambdas for C++ have been under work for a very long time. The first version of proposal to add them to C++0x is from 2006 (as far as I can tell) and it refers to papers dating back to 1988 which discuss adding "Lexical closures" to C++. So based on that, C++ committee used over 5 years to get lambdas on a release from a proposal. 2-3 years for Java doesn't sound that bad after all.

subwindow 15y ago

Backwards compatibility is great and all, but at what cost? One of the main reasons why Windows eventually started to collapse under its own weight was backwards compatibility. If a piece of software is so tied to backwards compatibility that it cannot change it will, necessarily, die. That said, statements like "Once added, you can't ever make any changes to lambdas" are obviously bullshit. Programming languages can and do successfully undergo significant changes. Ruby 1.9.2 is a completely different beast than 1.8.0 (including significant changes to lambda sytax), and I'd expect there are few (if any) applications that could be upgraded without significant changes. The same could be said for PHP 4 -> PHP 5, Perl 5 -> Perl 6, and Python 2 -> 3. Contrast those languages to Java, which is largely the same since 2001. Sure, there's a cost to everybody when you have to upgrade your app, but there's a much greater benefit when it is all said and done.

angelbob 15y ago
Ruby breaks these things. But Ruby is not generally even considered for a lot of what Java is used for. Those two things aren't independent. Don't get me wrong, I like Ruby far better than Java. But Ruby is simply not considered a stable enough language for your huge app that you plan to maintain for 20+ years... Nor should it be. Java is that stable. On the flip side, Ruby is improving much more quickly than Java. I write small apps I plan to maintain frequently far more often than I write apps that need to sail onward for 20+ years. Two different market niches, defined by two different groups of customers.
statictype 15y ago
One of the main reasons why Windows eventually started to collapse under its own weight was backwards compatibility. True. On the other hand, that backwards compatibility is an important reason why Windows was so utterly dominant for so long. It's (as always) a tradeoff.

eneveu 15y ago

Brian Goetz's talk on Virtual Extension Methods at the JVM Language Summit 2011 was pretty interesting in this regard: http://medianetwork.oracle.com/media/show/16999 http://medianetwork.oracle.com/media/show/16999 He explains why adding lambdas isn't that straightforward, due to backward compatibility, but also because it wouldn't make sense to add lambdas without updating the standard APIs to benefit from these lambdas. Some of these APIs, such as the collections framework, are interface-based. Adding methods to an interface would break backward compatibility, which led them to Virtual Extension Methods. For example, we could add a forEach method to the Collection interface without breaking backward compatibility: interface Collection<T> { // existing methods void forEach(Block<T> block) default Collections.<T>forEach; } When not overriden, this virtual extension method would default to calling a static method, Collections.forEach(Collection<T>, Block<T>), thus preserving backward compatibility.