Discussions

News: Are Java Closures Really Necessary?

  1. Are Java Closures Really Necessary? (24 messages)

    Even many experienced Java programmers wonder what closures are about. Brian Goetz, of Sun Microsystems, has written an excellent overview of closures and talks about the proposals in front of the JCP. In short,
    A closure is a block of code that may contain free (unbound) variables; these variables are not defined in the block of code or in any global context but instead in the environment in which the block of code is defined. The name "closure" comes from the combination of the block of code to execute (which, by virtue of free variables, is not closed with respect to variable reference) with an evaluation environment (the scope) that supplies bindings for the free variables.
    The closest thing that Java provides so far is support for anonymous classes. Adding closures to a strongly-typed language like Java may result in significant changes to the typing system because it must represent not only classes and primitives, but code as well. Smalltalk, Scheme, Ruby and other languages with closures support functions as first-class objects. Functions can be stored in variables, passed as parameters to other functions, and created dynamically and returned from functions. Solving this isn't a simple task, and there are at least two strong proposals to solve the issue, Concise Instance Creation Expressions and BGGA Nominal Closures. According to Neal Gafter, co-author of the Nominal Closures proposal, consensus has been reached, though at the time of this posting, no third-party has reported on said consensus. What do you think? Are these proposals solid? Has consensus really been reached, or are the BGGA folks counting the chickens early?

    Threaded Messages (24)

  2. FCM closures[ Go to top ]

    Unfortunately, Brian (and this article) chose not to include FCM closures, of which I am a co-author. This is despite it being a more detailed proposal than CICE, and being conceptually located between the other two, with the power of BGGA and the simplicity and Java-style of CICE. Smalltalk, Scala and Ruby follow a different language heritage to Java in this area. In my opinion, Groovy, Nice and F3 represent the way in which Java can be extended to support closures - and are the pattern which FCM (and CICE to some degree) follow. The Java community needs to decide if Java is still a relatively young language where new concepts can be added relatively freely, or a mature language where every new feature has to respect all aspects of the existing language, and the expectations of current developers.
  3. Re: FCM closures[ Go to top ]

    Unfortunately, Brian (and this article) chose not to include FCM closures, of which I am a co-author. This is despite it being a more detailed proposal than CICE, and being conceptually located between the other two, with the power of BGGA and the simplicity and Java-style of CICE.
    Hi Stephen, I was looking for references about all closures proposals and couldn't find a reference to yours when I wrote that up; for some reason all the debate was centered about CICE and BGGA. Thanks for clarifying this and now... it's part of this thread! Let the comments continue. Cheers, Eugene
  4. Re: FCM closures[ Go to top ]

    The Java community needs to decide if Java is still a relatively young language where new concepts can be added relatively freely, or a mature language where every new feature has to respect all aspects of the existing language, and the expectations of current developers.
    My feeling is that this has already been decided when erasure has been opted for implementing generics. Java is mature and evolves accordingly.
  5. Adding closures to a strongly-typed language like Java may result in significant changes to the typing system because it must represent not only classes and primitives, but code as well.
    The 3 proposals that I know enough about all do not add new concepts to the type system, except that BGGA adds a notation for achieving exception transparency through a limited extension to generics to allow a kind of vararg generics just for exceptions. BGGA does add a syntax for function types, but those are directly translated into interface types in a simple way. They're a notation, rather than a new semantic. The key parts under debate seem to be how to return values from within a closure - e.g., whether return returns from the closure or from the enclosing code.
    What do you think? Are these proposals solid? Has consensus really been reached, or are the BGGA folks counting the chickens early?
    From discussions, I think that a consensus has been reached in as far as everyone knows everyone else's position pretty well, the debate isn't heated, and there are a set of use cases that are understood. I hope that individual features are still going to be debated. FCM's semantics in non-void closures will probably make more sense to more Java developers than the BGGA semantics, though the BGGA semantics make perfect sense for void closures (by void I mean ones that don't return a value). I'm looking forward to the prototype.
  6. Not Really Needed[ Go to top ]

    Closures are being added because they're cool, that is the simple reason. I say, why not add some syntactic sugar to anonymous inner classes instead and loosen the requirement for "closed over" variables to not be final and solve 90% of the use cases in a "Java way". For a language that has been developed around closures they make perfect sense. Java had half-assed closures from day one (AIC) and adding proper closures on top of that, instead of fixing the original ones, will only make Java into a syntax soup. There's a bunch of things that should be added before closures and that really would add some value. These are (maybe) properties, defaults for method arguments and method references รก la FCS. Cheers, Mikael Grev
  7. Re: Not Really Needed[ Go to top ]

    Java had half-assed closures from day one (AIC)
    Not exactly. Inner classes came with Java 1.1. ----- Gustavo.
  8. Re: Not Really Needed[ Go to top ]

    Closures are not really needed for Java. We just need a simple solution for handle events and not the verbosity style of anonymous classes. It could be better for Java include like Delegates functionality as C# have, It works great for event programming. Delegates are more for Static typed programming languages, Closures are more for Dynamic typed languages. Look at C# with the new features it's getting bloated and ugly language. I think Java is mature and doesn't need more features but I would like it will be fixed the event programming in Java just adding as I said a simple solution for event handling could be Delegates.
  9. Re: Not Really Needed[ Go to top ]

    It could be better for Java include like Delegates functionality as C# have, It works great for event programming. Delegates are more for Static typed programming languages, Closures are more for Dynamic typed languages.

    Look at C# with the new features it's getting bloated and ugly language. I think Java is mature and doesn't need more features but I would like it will be fixed the event programming in Java just adding as I said a simple solution for event handling could be Delegates.
    You need to make up your mind, one way or the other. You're contradicting yourself all over the place in the space of a few sentences.
  10. Re: Not Really Needed[ Go to top ]

    Frank you are right. I think the event handling functionality in Java should be fixed but not bloated it to much. As I said I think Java is mature enough in all the aspects.
  11. Re: Not Really Needed[ Go to top ]

    Closures are not really needed for Java.
    Well, Java has done pretty well without them. However, if you read the specs (especially Gafter's) I think you'll realise the simplifying power of adding closures to the language (particularly where he talks about using them to "add" keywords to the language like "withLock" or "withFile") will be amazing. Having used them in Smaltalk, they are the #1 feature that has been missing from Java. Yes, some of it is syntactic sugar for AICs but not all of it. With generics, an awful lot of collection-manipulation is becoming very difficult to read and closures will help with that as well.
  12. Re: Not Really Needed[ Go to top ]

    Closures are being added because they're cool, that is the simple reason.
    The idea of using code blocks as first class object is very old. It was first introduced in Lisp in the 60s. It is a very powerful abstraction that can actually unwind a lot of the syntax that we use everyday. In fact, languages that have incorporated closures from the get go tend to be much lighter in syntax than those that don't. Closures, powerful idea and if it's cool... cool! -- Kirk
  13. Re: Not Really Needed[ Go to top ]

    In fact, languages that have incorporated closures from the get go tend to be much lighter in syntax than those that don't.
    I agree with you that languages that incorporate closures from the get go tend to be lighter. But how many people in this thread really believe that Java syntax will get lighter as a result of adding closures? Closures may be useful for certain things, but I doubt they'll do anything to make the language lighter or easier to learn. I started using Java 9 years ago, and I fell in love with the language because it was so clean and light and flexible and powerful all at the same time. For me, any solution they come up with for closures has to meet those same criteria and I don't see that with the CICE proposal. static Comparator reverseOrder(Comparator cmp) { return Comparator(T t1, T t2){ return cmp.compare(t2, t1); }; } WTF is that all about? How "light" is that, then?
  14. this is all right.[ Go to top ]

    i actually find this syntax all right comparing with other Closue proposals. CICE is not really a closure anyway. And you are missing the point, the example you give is sort of a generic based API design, end users mostly do not need to know details of it. Try writing an example using this facility, you will see what i mean. Closures in other languages are not easier then this by the way..
  15. I like the CICE proposal. Its much more simple to understand at the first glance. There is no new syntax but takes already existing features/capabilities of Java. Its easy to use. That's my one cent.
  16. Simple[ Go to top ]

    I started using Java 9 years ago, and I fell in love with the language because it was so clean and light and flexible and powerful all at the same time.
    Java has "evolved" to be a "bloated" language. There used to be a time when one was able to understand a multi-thousand line Java program basically by looking at the source. These times are long gone. Along came Templates, autoboxing, Anonymous inner classes (bloated, for what people need are delegates!). Now we are effectively looking at introducing "macros" to the language (yes, you call it "closures", but people *will* use it like c++ macros). What about multiple inheritence and operator overloading for a change?
  17. And then, objects came[ Go to top ]

    Closures are being added because they're cool, that is the simple reason.


    The idea of using code blocks as first class object is very old. It was first introduced in Lisp in the 60s. It is a very powerful abstraction that can actually unwind a lot of the syntax that we use everyday. In fact, languages that have incorporated closures from the get go tend to be much lighter in syntax than those that don't.

    Closures, powerful idea and if it's cool... cool!

    -- Kirk
    * Yes, and then in the late 70s, people realized that closure (state+code) could be more useful if they had a more defined interface, and a more defined state; learning from object oriented languages, they introduced objects (Flavors, at the time). Maurizio
  18. Soon, Java and C# will look so much alike that we won't know which one is the copycat of the other. The only difference will be that future original Java features will be copied by the C# team two years before their release on the next JVM, and future original C# features will be copied by the JCP two years after their release on the next C# language standard version (!).
    I'm not joking: could the Java guys just go slower than they already do ? Hard to imagine.... Concerning closures: they are damn useful in C# (or their equivalents: delegates and events), even if the syntax isn't particularly brilliant nor short. Can we just have them soon enough ? I've seen this discussion over and over again in the last two years !
  19. Yes they are![ Go to top ]

    I won't repeat all the convincing arguments for closures here, this is done by the authors of the proposal more elaborately. Fact is, that the Java language lacks some expressiveness. Just look at JSF and the upcoming JSR 295 (Beans Binding): Both of them use a weird, purely interpreted, script-like "Expression Language" (EL) just to get around certain limitations of Java. Using EL means that you have to clutter your code with string expressions which are not type-safe, cannot be refactored properly, and which are prone to subtle errors. Conclusion: If the most prominent UI-technologies for Java (JSF for the server-side, Swing for the desktop) cannot be designed using plain old Java, then fix Java. With Closures, you can fix a lot.
  20. Exercice[ Go to top ]

    For a practical exercise, try to imagine using closures to solve you day-to-day problems on your java job. I'm sure you will be surprised with the amount of problems that would be easier solved and become more elegant with a first-class method/function at least...
  21. Re: Exercice[ Go to top ]

    For a practical exercise, try to imagine using closures to solve you day-to-day problems on your java job. I'm sure you will be surprised with the amount of problems that would be easier solved and become more elegant with a first-class method/function at least...
    Not easier but more compact. And you will in general be surprised of the amount of work that maintaining a codebase someone else wrote without formal interfaces will generate. But hey, hacking it all together was fast and fun alright :-).
  22. I have blogged my response to the JSR announcement. In summary I'm giving the JSR a cautious welcome, but wish to emphasise that there is no new consensus beyond that there should be a JSR. Stephen Colebourne co-author FCM closures
  23. Yes They Are![ Go to top ]

    Closures should be a welcome addition to the core Java language for a couple of reasons: 1. Treating functions as first-class entities in a programming language is a powerful capability, even if the syntax is not as elegant as one might have hoped for (ostensibly due to the retrofit). 2. Java needs to continue to evolve to survive The argument about Java already being bloated are obviated when considering the motivation behind this argument: that it increases the learning curve of the language, or detrimentally extends/affects the nomenclature. To this I propose that a primary design goal for Java should not be 'learnability', and that the syntactic investment will pay dividends with the increased elegance of the resulting code. BGGA closures feel more like the real thing, while CICE resolves syntactic problems inherent to anonymous classes. I feel there is room for both, at least conceptually. Meanwhile, if you don't like closures, don't use them - but don't prevent the rest of us from doing so! Does this remind anyone else of the adage, "Any programming language that evolves long enough turns into Lisp"? :-) Have fun
  24. Someone please explain to me in simple terms: 1. Will closures allow me to do things in Java that I cannot currently do? 2. Is the principle value of closures the fact that I no longer need to use "ugly" anonymous inner classes? 3. If the answers to the above are no,yes respectively (as I expect), doesn't anyone out there think that the IDE rather than the language/interpretor might be a more appropriate place to solve this particular "problem"? 4. If the answers to the above are not what I am expecting could someone please elaborate on the value of closures without reference to official definitions because I really feel like I'm missing something here. Thanks all, Anthony
  25. 1. Will closures allow me to do things in Java that I cannot currently do?
    It depends on which proposal you examine. There are two possible new features you can't do today. The first is to escape directly from a closure (inner class method) to return from the enclosing method which defined the closure. This can be useful in certain use cases for closures, but you probably won't have come across them up until now. (supported by BGGA) The second is control abstraction, where you can write an API method which you can use in a manner similar to that of a built in keyword. These would be used for resource acquisition, looping around maps and lock management for example. (supported by BGGA and FCM+JCA)
    2. Is the principle value of closures the fact that I no longer need to use "ugly" anonymous inner classes?
    A nicer syntax for inner classes should also be a benefit. (supported primarily by FCM and CICE, but also BGGA to some degree).