Would you like JDK 7 to support closures? | Java.net

My pages	Projects	Communities	java.net

Get Involved About java.net Request a Project Publicize your Project Submit Content java-net Project Java.net Enhancements Site Help Report Inappropriate Content Get Informed Articles Blogs Events java.net Online Books java.net Archives Get Connected java.net Forums Wiki Javapedia People Partners Jobs RSS Feeds Java User Groups Search Web and Projects: Online Books: java.net on MarkMail: Advanced Search
		Would you like JDK 7 to support closures? Yes 41% (435 votes) No 21% (222 votes) Not sure 10% (108 votes) What's a closure? 27% (287 votes) Total votes: 1052 » Login or register to post comments 389 visits Printer-friendly version In the "not necessary" camp Submitted by gkbrown on Wed, 2008-01-09 08:52. Closures are handy in JavaScript, but Java doesn't need them. Inner classes are sufficient (and preferable). Login or register to post comments WIll they be serializable? Submitted by cobrien on Thu, 2006-08-31 11:06. If they are serializable then they can be used for things like workflow. That's what I'd like to see. Login or register to post comments WIll they be serializable? Submitted by tompalmer on Thu, 2006-08-31 16:06. Maybe you are thinking of continuations? Login or register to post comments allow inner classes to access non-final local variables Submitted by mstevens on Thu, 2006-08-31 03:57. I want closures, but from what I've read of the proposal it doesn't seem very java-ish. I think something that would keep java java-ish would be to allow anonymous inner classes to access non-final local variables - this my biggest problem with using anonymous inner classes to simulate closures. They'd still be extremely verbose, but you can't have everything :) Login or register to post comments Better Idea Submitted by jackdog on Wed, 2006-08-30 17:02. I would rather Sun just focus on real world issues such as transparency in JWindows or non-rectangular JWindows. These two limitations are severly hindering modern rich clients. Login or register to post comments No More Language Changes for a While Submitted by jmoore on Wed, 2006-08-30 04:29. Please, no more language changes for a while. Give the Java community time to digest the last batch of langauge changes in Java 5.0. New library APIs, changes in existing library APIs, improvements in performance (especially startup times), etc. are all fine with me, but not changes to the language itself. Login or register to post comments I love closures, but... Submitted by archangel on Wed, 2006-08-30 03:37. I fell in love with closures in Ruby and Groovy, but I think adding them to Java isn't a good idea. My issues are these: Why? What are the use cases for closures? These solve some problems, sure, but is it really so important that we need a major language change? Is someone going to go back and rewrite the collection APIs to take advantage of these? How about the Swing listener mechanism? Personally, I would like to see the following poll added to java.net: "Should Sun create a new statically-typed language rather than add new features to the Java language?" My problem is that I think Java is getting harder and harder to learn and teach. I would like to see a new statically-typed language with proper templating, closures and all the other things that people like from other languages with a single, unified approach. Like Groovy, as it's in the JVM it'll be able to interact very easily with existing Java code. This means Java stays nice and stable and the wizzy features can be added to a new language - "Java 2" (the marketing people will love it!). Login or register to post comments No thanks Submitted by jkeatley on Tue, 2006-08-29 06:04. This reminds me of the overzealous motorhead teenager that wants to soup up Dad's Ford. He needs his own car to do with what he wants, because Dad needs the Ford to go to and from work. Maybe the extra-features group needs to create a new language. Then they can junk it up to their hearts content. Leave Java alone! Login or register to post comments Better syntax maybe Submitted by pcwheels on Mon, 2006-08-28 07:04. I would like to reference Methods in Java. But isn't there a nicer way to do this? One that is closer to the syntax we already know. For example: Method anIstanceOfMethod = someObject#someMethod(); anIstanceOfMethod.execute(); Generics could then be used to specify the return and parameter types of the method. Login or register to post comments Better syntax maybe Submitted by jwenting on Mon, 2006-08-28 10:36. you could just do someObject.someMethod() and have the method execute without getting that Method object first... Login or register to post comments Better start from 1.4 Submitted by weberjn on Mon, 2006-08-28 01:27. I'd rather have the templates thrown out and start Java from 1.4 again. Login or register to post comments Not needed - further clutter Submitted by gbilodeau on Sun, 2006-08-27 11:54. I fall in the "closures seem like syntactic sugar for anonymous inner classes" camp. Sure, anonymous inner classes are ugly, but they are consistent with the whole object-oriented paradigm and relatively easy to read. This was the whole point of Java: being a truly OO language that shedded all the complexity and ambiguity from C++ and other languages. Anyways, I don't see anonymous inner classes used too often. Sure, it would make a few classes shorter (Swing-based dialogs with event listeners and classes doing collection filtering), but they are far and few between. Closures would not increase greatly the overall readability and maintainability of my applications. Don't spend energy on increasing the complexity of the language to appease a highly vocal minority of dynamic language users. As was expressed earlier, there are features that are way more important right now and in the next ten years: proper packaging, better support for native execution, bug fixes... Login or register to post comments Not needed - further clutter Submitted by jwenting on Sun, 2006-08-27 21:22. and most of all stability. We don't need a major upheaval of the programming paradigms and language syntax every 2 years. Login or register to post comments No please. Submitted by kdwinkler on Sat, 2006-08-26 19:45. Based on what I've been reading on the net there is already a growing feeling of serious discontent with the changes in 1.5. I had hoped I would be able to program in Java for another 10 years or so, but it looks like this is the beginning of the end. Login or register to post comments No please. Submitted by rickcarson on Mon, 2006-08-28 18:08. I thought adding templates to the language in the guise of Generics would turn it into C++. Before that I thought adding Regular Expressions to the language would turn it into Perl. Fortunately, neither of those things have happened. the world has not ended, for those of us doing real work instead of sitting in Ivory Towers there was not much difference. At the end of the day if I run across some bad code with bugs in the Template/Regex/Fancy For Loop/Enums/Autoboxing I can always just turn it back into it s "verbose" form to debug it properly. Closures is no different. So some eggheads want to add some feature so that they can save 10 or 15 keystrokes by not having to create a proper interface? Their loss. Interfaces are great, they are the proper way to do OO in Java, and most of those examples of things that they've added to the language when you get right down to it betray that at a fundamental level these people are just not smart enough to truly 'get' OO. Well, so they want to make some bad looking syntax. So what? Yes, it is bad, evil and wrong. But they will just go ahead and do it anyway, because there is no way to vote 'No'. That is the bad news. And you know what? It is not that bad. Life will go on. They will go back to the ivory tower and try to copy some other Lisp feature (Macros anybody?). The world will not end. The good news though, is very good. Generics are yucky, but can be ignored or fixed. No big deal. Where the real pain points were was in Enterprise Java. Web services under J2EE 1.4 were truly horrible. EJBs were ugly and an enormous pain. Did you ever havfe days/weeks/entire projects where you spent more time fiddling the XML than programming in Java? That was J2EE then. Java EE 5 is fantastic. Annotations (particularly good example with JAX-WS and annotations) take out so much pain that it more than makes up for all the stupid little things they try to do to Java. Introduce EL to Java (and how much sense does adding another language to an already Turing complete language make?)? Pfft. Insist on everyone using spaces instead of tabs, and no variable name shorter than 70 characters and no line of code longer than 80? No problem. Change all the keywords to ancient Sumerian? I laugh in their general directions. In computing there are two competing forces. The people trying to make simple things more complicated, and the people trying to make things elegant. What is elegance? Some people think that brevity /succinctness is the important part of elegance. But every example of true elegance that I can think of is something where you can show someone else the code and they understand it and can almost straight away say "hey! That's cool!". Communication is at the heart of true elegance. It is not enough to find a clever way to shave off keystrokes, but the cleverness must be self communicating. There must be an element of readability and obviousness. If it requires a detailed explanation of how it works, it may well be 'clever', but it is not elegant. Closures are not elegant in Java. Login or register to post comments Closures is not what Java needs most... Submitted by kopepi on Sat, 2006-08-26 07:01. What Java really needs right now is bug fixing and a new deployement system. Users don't want jars, developers don't want platform specific binaries, Sun has to do something and not add to java some magic tricks that will not only not appeal Ruby devs but rather repeal current Java devs. Don't get me wrong, I'm fond of generics and other new stuff that got into Java 5, but how am I supposed to tell a regular user to instal the latest java vm before double-clicking my jar ? Why do I have to tell them to do a command line java -jar -Xmx because their app behaves strangely though no error shows up ? How are they even supposed to do that when they can barely tell what command line is ? I hope I'll get an awnser from Sun someday... Login or register to post comments Closures is not what Java needs most... Submitted by ewin on Sun, 2006-08-27 00:43. Don't expect to get an answer for Sun. They are seriously disconnected from real-world programming and to arrogant to take the opinions of bread-and-butter programmers into account. They probably never stood in front of a customer who threatens your entire existance by withdrawing from the contract if you don't fix a "cosmetic" bug. A bug caused by the fact that Java doesn't play nice with the host operating system. Or they never lost money because Sun suddenly out of the blue withdraw a complete API implementation (JavaComm for Windows) and you had to stop shiping a software until ported to a more trustworthy alternative. And the Sun Java developers are probably bored to death. That would at leat explain why they come ou with one stupid idea and half-baked implementation after the other. Oh, I could keep them busy for years. I would relegate that bored arrogant bunch to fixing each and every bug in the bug parade. Login or register to post comments Closures is not what Java needs most... Submitted by larswestergren on Sun, 2006-08-27 23:27. Don't expect to get an answer for Sun. They are seriously disconnected from real-world programming and to arrogant to take the opinions of bread-and-butter programmers into account. Wow, bitter today, are we? I have been reading the blogs at java.net, and I see a lot of open and vigorous discussion about what to include and not. I agree with one thing though, I too would like to see a "stability and polish" release that fixes (among other things) Swing and AWT bugs. However, it seems you and me are in the minority. If you read what people are saying, it seems more people ask for "new cool feature X" rather than bug fixes. With regards to the grandparent post, there was one guy who blogged here at Java.net who worked at Yahoo. He wrote an article about what he would like to see most in Java - a modular JDK integrated with webstart, that is very slim to begin with and only downloads what is required. Plus some other ideas that could make Java compete better with other client platforms such as Flash. This article was linked to by many, and now this guy (forgotten the name, Nate something?) got hired by Sun... Login or register to post comments Closures is not what java needs... Submitted by kopepi on Sat, 2006-08-26 06:59. What Java really needs right now is bug fixing and a new deployement system. Users don't want jars, developers don't want platform specific binaries, Sun has to do something and not add to java some magic tricks that will not only not appeal Ruby devs but rather repeal current Java devs. Don't get me wrong, I'm fond of generics and other new stuff that got into Java 5, but how am I supposed to tell a regular user to instal the latest java vm before double-clicking my jar ? Why do I have to tell them to do a command line java -jar -Xmx because their app behaves strangely though no error shows up ? How are they even supposed to do that when they can barely tell what command line is ? I hope I'll get an awnser from Sun someday... Login or register to post comments Closures is not what java needs... Submitted by rickcarson on Tue, 2006-08-29 16:45. Executable jars rock my lame world Login or register to post comments Its just a contributory factor to complexity than a language fea Submitted by endlesslove on Fri, 2006-08-25 22:26. Isn't closure simulated through inner classes? There's a pro java closure argument that says inner classes can't use a local variable unless it is final, so we need to add closure in the Java language. But does it hurt to make that variable an instance variable so the innerclass can access it, as what everyone has been doing? If you say it doesn't hurt but it's just ugly, I'll say, for me it's beautiful. If you say it's hard to type, I say, for me it's easier. If you say it's harder to read an innerclass than closure syntax, for me it's not. If the Java language will evolve just because of some people's laziness to type and their own views of aesthetics, how about those programmers that value consistency and simplicity of the Java Language? Please add something to the Java Language if that 'something' is so valuable and unavoidable, for the sake of simplicity and consistency. (Please don't counter-argue and tell me to go back to assembly or C. I also like evolution in the language as long as it is towards the better.) Login or register to post comments let's not mess up the language even more Submitted by jwenting on Fri, 2006-08-25 22:14. Why is Sun adamant to add the worst feature of every other language under the sun to Java? Are they on a self-destruct heading or something? Let's keep the language usable rather than a mess of things that just make code unreadable that are added because "XXXXX has it also so if we add just that one more feature we get a lot of people who now use XXXXX to use Java instead". That's not how the world works, most people not using Java either have very good reasons to or are the open source zealots who think everything should be written in Perl. Login or register to post comments Perhaps useful, but not enough Submitted by prunge on Fri, 2006-08-25 19:38. I can see where closures would be useful, but I could live without them. I don't think they offer enough improvements to warrant the cost of changing the language. Login or register to post comments closures Submitted by dog on Fri, 2006-08-25 08:50. I'm not sure. I love closures.. but in Java I use annonymous classes for the same effect. So why do I need the new syntax (I understand that there are some differences). However, I would prefer if I didn't have to declare an interface to do a closure.. that would make it very limited (I browsed through the proposal posted yesterday and that is what I remember). I would just like to run: `Collection col = collection.collect( (each) { transform(each) });` And the datatype of the closure would be Closure (or Block if you prefer) but there could be subclasses for 1, 2, 3, or variable args. That brings me back to my original question.. isn't this just syntactic sugar for inner classes? Java made mistakes because it was affraid of C#, now Ruby appears and we have to cave in to that new trend? What's next? Declarative Java? (O crap, they already added that.. annotations). Login or register to post comments Syntactic sugar is sooo sweet Submitted by jhannes on Fri, 2006-08-25 11:49. Yup, closures can be simulated with anonymous inner classes. But anonymous inner classer are really, really sour, and do need some sugar. Give me some of that sweet, sweet syntactic sugar. Yeah! Login or register to post comments Syntactic sugar is sooo sweet Submitted by dog on Mon, 2006-08-28 12:40. If that's the case then Java already has closures. We don't need it. I don't see the value of complicating the language for a feature we already have. I'm sorry it's too hard to implement inner classes.. but I don't think it's worth changing right now. Apache commons-collections already has cool functions like the select, collect, reject smalltalk had. If you want to add those to the Java library.. fine! But I don't see the need for a new language feature if all its going to be is syntactic sugar. If we MUST do it then just make it a simpler syntax for annonymous classes but now new sorts of declarations. Ex: `// instead of addActionListener(new ActionAdapter() { public void actionPerformed(Event evt) { ... } ); // make it (w/o adding new weird declarations) addActionListener( new ActionAdapter.actionPerformed(Event evt) { .... });` Still just as ugly though. Are closures even cool in a statically typed language? Login or register to post comments I have nothing against closure but I don't like the syntax that Submitted by vbrabant on Fri, 2006-08-25 08:25. closure seems to be powerful, also it seems to simplify how I have to write my code (specially when you have to create anonymous objects). But I really hate the syntax that has been choosen therefore. So, if closure must be introduced with the syntax that has been proposed, for me is NO. Login or register to post comments I have nothing against closure but I don't like the syntax that Submitted by xmirog on Sat, 2006-08-26 03:14. I agree with you, I'd like to have closures in Java, but the chosen syntax of Closures and Function types is not clear and simple enough (in my opinion). I think more time should be spent to get a simpler syntax for it. Login or register to post comments while we're at it, Submitted by ilazarte on Fri, 2006-08-25 08:19. let's at a goto statement. it's clean, very easy to read, and i can get joy from programming with it. preferably it looks like the goto statement from basic, since I don't like what goto would look like if it had to be java-fied. Login or register to post comments while we're at it, Submitted by alski on Fri, 2006-08-25 08:53. Add "goto"? It's already there along with the damn labels to support them. I was shocked when I was reviewing some code of a coworker and it was littered with them. Man, it makes coding a joy! Keep closures out, I'm with the anonymous inner crowd. If they don't cut the mustard then so be it... Login or register to post comments Closures yes. Function types no. Submitted by tjpalmer on Fri, 2006-08-25 08:09. I've seen tons of buggy code in Java that would likely have been a lot more solid (and easier to have written) if Java had closures. Try out a language with easy and extensive closure use, and it becomes clear. It's EASIER to program with closures. It's easier to write more READABLE and more SOLID code. That said, I think function types are a bad idea. Single method interfaces would work just fine, and it's easier to define the semantics around them. And someone else pointed out recently on a blog that JavaDoc turns into a nightmare for function types as parameters or return types. Yes to pretty closure syntax (and with the Ruby-esque block version, too). No to function types. Login or register to post comments About time & great suggestion Submitted by eirikma on Fri, 2006-08-25 07:14. First I must say that it was about time! When I switched from simula, inner classes and "method parameters" where sorely missed. The first was fixed in 1.1, the other is adressed now and in a very respectable way , too. Second, I think the suggestion in it self is great, except for non-local returns which I think only complicates stuff without adding any significant benefit. Also, the "further ideas" found in Neal Gafter's blog seems to me like a real miss. The Java language _could_ have been designed to accept calls to any method without parantheses around the parameters, just like in (visual) Basic, but, in fact, it is't because it makes the code less readable. Allowing that for certain kinds of methods and calls is definately not a good idea. Login or register to post comments Hard choice Submitted by larswestergren on Fri, 2006-08-25 06:03. I have been following the discussions about this with interest. The con side makes some very good points, but all in all I think I prefer to have them. Login or register to post comments About time! Submitted by ctreber on Fri, 2006-08-25 05:18. Login or register to post comments