Stronger Java, no sugar please

February 27, 2007 – 00:14 | java

I just wanted to expand on Richard Relos’s we don’t really need closures in Java into a broader argument – syntax sugar is the least of what Java really needs now.

The beauty of Java the Language, IMHO, is its simplicity. Many people, including myself, coming from a C/C++ background immediately appreciate the fact that there is much, much less surprise in code written in Java. Every spoonful of syntax sugar added to the language adds to the conceptual complexity of the language, not linearly, but exponentially, as every new construct has to work well with everyone that’s already in there. On the other hand, it only makes things easier superficially. What does a closure gain us? A few lines of less typing? Or maybe just a few key strokes in any of the modern IDE’s these days?

Many people say that closures are easier to learn for beginners than anonymous classes. I wouldn’t be so sure. For instance, which one is easier: to explain to a student that that mysterious Foo$1.class is actually generated from a closure which, whilst not being a class conceptually, actually is handled as an anonymous class? or to explain to him that an anonymous class gets compiled into, well, a class?

Furthermore, should everything that makes Java easier to use make into the language? Dependency Injection/IoC Containers have become more and more widely adopted, but that doesn’t mean Java should necessarily incorporate Spring or Hivemind’s definition syntax, does it?

Some people say syntax sugar is supposed to make Java easier to use, so it can compete with RoR, .Net, etc. I agree to the goal, but not the means. IMHO, the changes that Java, especially enterprise Java, needs in order to go up against Microsoft and RoR/the whole LAMP camp have to be much, much more fundamental than throwing in several sugar cubes. EJB 3 is a good move in that direction, as Java admits that miserable mess happens when the principle of simplicity is forgotten. But there is yet a lot left to be desired, for example, until JVM starts supporting compartmental deployment, i.e., multiple applications running and managed in isolation, there is no hope for Java to become a strong offering in the Web hosting market. Unfortunately, AFAIK, JDK 7 has yet no plans of supporting that.

Trackback from your site, or follow the comments in RSS.
  1. 5 Responses to “Stronger Java, no sugar please”

  2. Whilst I would agree with the sentiment of your view, I would add (emphasis?) that syntax sugar has its place (my pet hate is writing plain old getter/setters – something simple and a great time saver).

    In regards ‘compartmental deployment’, I would not put that in a ‘syntax sugar’ category. However, I agree such capability is highly warranted and add: within a broader server capability (a new, super, simple Java Server if you will – definitely no EJB legacy).

    Simon

    By Simon Cition on Feb 27, 2007

  3. Actually, closures add far more than syntax sugar if done properly. They make it possible to express some kinds of APIs that are not possible or practical to express today. See http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java Admittedly there are alternative proposals around that are merely syntax sugar.

    By Neal Gafter on Feb 27, 2007

  4. I have a somewhat orthogonal opinion on this subject. Syntactic sugars always have their place in a programming language – Microsoft has at last realized it. I had blogged about my thoughts on adding syntactic sugars in Java in http://debasishg.blogspot.com/2006/10/why-oop-alone-in-java-is-not-enough.html.

    By Debasish Ghosh on Feb 28, 2007

  5. Less complexity ==> More adoption. Please don’t make this an elitist language. Just add enough functionality maintaining the KISS principle. Sytantic sugar is nice as long as there are no gotchas. Hopefully the community learns from the botched generics in Java when compared to C#.

    By Kris on Apr 3, 2007

  1. 1 Trackback(s)

  2. Feb 28, 2007: Pure Danger Tech » Blog Archive » Java 7 Roundup (Feb 28th)

Post a Comment