Why I think CICE is too complex for the gain

October 11, 2006 – 22:55 | java

IMHO, Concise Instance Creation Expression, the Lee-Lea-Block Proposal for Closures in Java, carries a more hefty price tag than it seems:

  • In CICE, at least for Java beginners, it's not obvious at all that a new class is defined and a new object instance created, because of the absence of "new". Even with the "class" in "Anonymous Class", all the time we have been hearing questions like "what's this Foo$1.class thing doing in my classes folder?" Imagine if you have to start the explanation with "yeah, a closure is really a class under the hood..."
  • With modern IDEs, it's only a couple of mouse clicks or key strokes to create an anonymous class boilerplate, so I don't see any big saving on that front.
  • This one's probably more of a personal taste issue. I just think there is a bit too much magic in the "automatically expose a local variable if it's assigned exactly once" rule. The only gain I can see here is pretty nominal - not having to explicitly type the keyword "final"? Is that really a gain? I am not convinced. For anybody other than the code author, they can no longer tell a variable is final or not when they see something like
    JAVA:
    1. int numCompares=0;

    because nobody knows maybe a couple of screens later this variable is invoked in a closure.

  • I like the ability to declare mutable local variables public and make them available to closures. It scratches the it's-gotta-be-final itch. However, I don't see this particular piece have anything to do with closure. A public local variable can just be as easily accessible from an anonymous class. I'm all for it if this part is singled out as another proposal.

Let me wrap this up with a trivial rant :) - it doesn't seem objective to compare

JAVA:
  1. new Thread(new Runnable() {
  2.   public void run() {
  3.     foo();
  4.   }
  5. }).start();

with

JAVA:
  1. new Thread(Runnable(){ foo(); }).start();

instead of

JAVA:
  1.   foo();
  2. }).start();

for obviously the one liner only makes sense in the simplest examples.

Trackback from your site, or follow the comments in RSS.
  1. 5 Responses to “Why I think CICE is too complex for the gain”

  2. Addressing your points in order:

    - The underlying implementation needn't be obvious.
    - Yes, IDEs make coding anonymous classes trivial, but this proposal is about readability more than writability.
    - Yes, the local variable scoping rules are orthogonal to closures. You could write a separate proposal, but I like the context.
    - As for adding line breaks to the example, it's still a marked improvement.

    By Bob Lee on Oct 13, 2006

  3. It is a marked improvement. I still think new Thread({foo();}).start() is even better in terms of expressing intent. It's not so much 'magic' as 'inference'.

    By Ricky Clarkson on Oct 14, 2006

  4. Lee-Lea-Block and all the other closure guys, I still think they are basically bored. To fight being bored they invented closures. I admire many of them for the great work they did. But even those guys did mistakes in the past regarding java. Take a look at doug leas comments about the 'old' java memory model...So, no inerrable gods that we praise :-)
    As I have learned, from java 6 on there will be a feature removal process. If closures are going to make it, I would suggest them for immediate removal. Why do I hate closures?
    Nobody realy needs closures in java! There is NO use case except one of syntactic nature. Is this feature-itis, inventing feature for the sake of feature?
    Say you have a project. Say you have two programmers. A java-old-fashioned guy prefering the damn-old-anonymous-inner-class style and a newbee which is the allways-up-to-date programmer guy. Aha - a project with two syntaxes for the same purpose. Uh? would be nice to make cross code reviews. Would be nice to do quality assurance. Closure adds unnecessary complexity not only to java but to the project in may example!
    If you give the chance to express one and the same thing in many different ways then those ways will be explored. And? What have you created? Do you have created "information". No! It's redundancy you're going to create. And I don't like redundancy!

    I cite a guy from theserverside.com (http://www.theserverside.com/news/thread.tss?thread_id=42535#219930)
    "Java hasn't yet enough rough edges to overtake C++ as the most complicated mainstream language. Joint effort is necessary to make it happen in the next release." Nothing more to say

    Cheers,
    Soylent Green

    By Soylent Green on Oct 14, 2006

  5. Bob,

    On your first two points - I agree in general that the underlying implementation needn't always be exposed - in most of the cases even better off not exposed. However, this particular "implementation" isn't very well hidden in the first place due to the fact that there are extra classes created under the hood. Like I said, this has been a major confusion spot for people even as it is with anonymous classes, the obscurity of closures would only make it more confusing.

    On the line break issue, it won't be as impressive when you have more than one line in the body. I don't think most people would like to write "new Thread({foo(); bar();}).start;"

    By Jing Xue on Oct 14, 2006

  6. and i don't know, how to make it bette. Anandi Hristina.

    By Anandi Hristina on Sep 19, 2007

Post a Comment