Step away from the compiler

Step away from the compiler

Summary: Java 5 changes were bad enough; let's not repeat the mistake. If you want to program in Ruby, then program in Ruby and be done with it, but leave Java the language alone.

TOPICS: Open Source

Earlier this month, Sun engineers proposed extending the language for Java 7 to include closures and local functions. In his blog, Neal Gafter wrote:

Modern programming languages provide a mixture of primitives for composing programs. C#, Javascript, Ruby, Scala, and Smalltalk (to name just a few) have direct language support for function types and inline function-valued expression, called closures. A proposal for closures is working its way through the C++ standards committees as well. ... We anticipate that the additional expressiveness of the language will simplify the use of existing APIs and enable new kinds of APIs that are currently too awkward to express using the best current idiom: interfaces and anonymous classes.

Years ago, Sun considered and rejected bound method references, which are essentially the same as local functions. The reasons given were efficiency and simplicity, though the real reason might have been that Microsoft had introduced the feature unilaterally in Visual J++. Now however, Sun considers C# and Ruby to be competition for the Java language. One part of Sun wants to embrace new languages on top of a universal VM, such as Groovy and JRuby and JavaScript. However another part wants to tack on new language features to make Java "sexier". None is sexier than closures, one of the defining characteristics of Ruby.

My take on it is this: in the real world, many Java developers are still not allowed to use Java 5 language features like generics (though that's likely to pass within the next year). Language changes just fragment the community and put up barriers to free Java implementations like Harmony, Eclipse, and gcj. As a developer I completely understand the irresistible drive to put in fresh new stuff, and I'm very good at coming up with perfectly plausible and logical reasons for it (I hope my manager isn't reading this). But Java language changes have a terrible and long lasting ripple effect on everybody down the chain. If anybody else besides Sun were proposing this, Sun would have a cow. Surely, those language developers can find much better things to do with their time.

Java 5 changes were bad enough; let's not repeat the mistake. If you want to program in Ruby, then program in Ruby and be done with it, but leave Java the language alone.

Topic: Open Source

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Weak

    So Java should stand still so open source can keep up while closed source .Net and C# stay on the leading edge? I wonder how MS would respond if the mono group made the same argument?

    I don't care for the closures spec either. In the end they just don't add much. At least inner classes are classes and not function pointers.

    Then again, if Sun/JCP decides to add closures, it really won't be the end of the world either.
  • Not delegates at all...

    See for an explanation of why closures are much different from bound method references.
    • Bound method references

      I wasn't comparing closures with bound method references, I was comparing local methods with bound method references. Those seem pretty much the same, aren't they?
      Ed Burnette
  • Language features

    I agree that closures shouldn't be added to Java, but disagree about adding language features.

    Personally, I really like generics. No, they're not perfect, but they IMHO they better serve they're purpose than C++ templates (although templates are a lot more powerful and can do many other things) and provide enough type safety. Generics hit the common 90% without boxing you in.

    I think Sun should focus on adding language features that make "good practices" easier and have relatively straightforward functionality.
    Erik Engbrecht
    • Generics are too verbose

      Generics are far too wordy for my taste. You end up repeating yourself two, maybe three times on complex types. If they had been accompanied by some kind of type inference they would have been more palatable.

      Additionally, you can do some pretty unreadable things with generics and wildcards. They're ripe for misuse, especially by less experienced programmers. I suppose the same argument could be made for operator overloading though it comes in mighty handy in languages like Ruby.

      I think Sun should focus on fixing bugs and solving real problems, like that problem where you can't delete a file that has been memory mapped even after closing it.

      I'd also like to see them work with others to come up with a common interface between the VM and the libraries so you could switch them independently. This was demonstrated in Harmony but Sun's response was that it was too hard.

      Finally I'd like to see them invent a new language that was run-time compatible with Java but had a clear and consistent vision without legacy issues.
      Ed Burnette
  • Underlying support is more important

    As a JRuby developer, I'm more interested in the changes that might come along with closures support in Java. By modifying the JVM to support such structures, it would make many things easier for folks like me trying to implement dynamic languages on top of the JVM. I'm not as concerned about the addition of closures to the language, though I think they'll be very useful. But supporting closure-like structures at the VM level will make many things possible.
    • Not likely...

      It seems likely to me that any support for closures in Java would just be syntactic sugar for anonymous inner classes, not with a new JVM instruction. Then they might further optimize anonymous inner classes (or class loading in general) to help improve performance.
      Erik Engbrecht
    • VM extensions

      How about a way to extend the VM, basically invent your own bytecodes?
      Ed Burnette