Showing messages 1 through 36 of 36.

• In the "not necessary" camp
  2008-01-09 07:52:11 gkbrown [Reply | View]
  
  Closures are handy in JavaScript, but Java doesn't need them. Inner classes are sufficient (and preferable).

• WIll they be serializable?
  2006-08-31 11:06:44 cobrien [Reply | View]
  
  If they are serializable then they can be used for
  things like workflow. That's what I'd like to see.
• WIll they be serializable?
  2006-08-31 16:06:18 tompalmer [Reply | View]
  
  Maybe you are thinking of continuations?

• allow inner classes to access non-final local variables
  2006-08-31 03:57:09 mstevens [Reply | View]
  
  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 :)

• Better Idea
  2006-08-30 17:02:12 jackdog [Reply | View]
  
  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.

• No More Language Changes for a While
  2006-08-30 04:29:33 jmoore [Reply | View]
  
  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.

• I love closures, but...
  2006-08-30 03:37:21 archangel [Reply | View]
  
  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:
  
  
  
  1. 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?
  
  
  
  2. 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!).

• No thanks
  2006-08-29 06:04:57 jkeatley [Reply | View]
  
  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!

• No more clutter, please
  2006-08-28 11:54:40 fabriziogiudici [Reply | View]
  
  "I fall in the "closures seem like syntactic sugar for anonymous inner classes" camp."
  
  Count me in. BTW, I don't find anonymous inner classes so ugly - and in any case with a bit of work, they can removed by ad hoc solutions using introspection and annotations (see for instance this example).
  
  One of the premises of the Java language was to keep it simple. After ten years is no more so simple (even though is still much simpler than C++). Please let's try to contain the complexity.

• Better syntax maybe
  2006-08-28 07:04:51 pcwheels [Reply | View]
  
  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.
• Better syntax maybe
  2006-08-28 10:36:17 jwenting [Reply | View]
  
  you could just do someObject.someMethod() and have the method execute without getting that Method object first...

• Better start from 1.4
  2006-08-28 01:27:43 weberjn [Reply | View]
  
  I'd rather have the templates thrown out and start Java from 1.4 again.

• Not needed - further clutter
  2006-08-27 11:54:17 gbilodeau [Reply | View]
  
  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...
• Not needed - further clutter
  2006-08-27 21:22:18 jwenting [Reply | View]
  
  and most of all stability. We don't need a major upheaval of the programming paradigms and language syntax every 2 years.

• No please.
  2006-08-26 19:45:46 kdwinkler [Reply | View]
  
  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.
• No please.
  2006-08-28 18:08:40 rickcarson [Reply | View]
  
  

  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.

• No please.
  2006-08-30 01:54:22 vhi [Reply | View]
  
  Well said!
  
  I do love closures. Just look at Ruby to find out its elegance.. But I think it is too late for Java to have closures. The syntax will get ugly, no core APIs would use it, and we would end up having one more way of doing things, sacrificing homoginity.
  
  It would be better if Sun adopts another language for the Java platform. One good candidate I think is Scala (http://scala.epfl.ch/docu/).
  
  I think the only way is to take a clean break and support a new language. Let's call it refactoring of languages :-)

• Closures is not what Java needs most...
  2006-08-26 07:01:00 kopepi [Reply | View]
  
  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...
• Closures is not what Java needs most...
  2006-08-27 00:43:30 ewin [Reply | View]
  
  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.

• Closures is not what Java needs most...
  2006-08-27 23:27:43 larswestergren [Reply | View]
  
  

  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...

• Closures is not what java needs...
  2006-08-26 06:59:16 kopepi [Reply | View]
  
  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...
• Closures is not what java needs...
  2006-08-29 16:45:18 rickcarson [Reply | View]
  
  Executable jars rock my lame world

• Its just a contributory factor to complexity than a language feature in Java
  2006-08-25 22:26:47 endlesslove [Reply | View]
  
  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.)

• let's not mess up the language even more
  2006-08-25 22:14:20 jwenting [Reply | View]
  
  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.

• Perhaps useful, but not enough
  2006-08-25 19:38:41 prunge [Reply | View]
  
  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.

• closures
  2006-08-25 08:50:00 dog [Reply | View]
  
  

  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).

• Syntactic sugar is sooo sweet
  2006-08-25 11:49:00 jhannes [Reply | View]
  
  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!
• Syntactic sugar is sooo sweet
  2006-08-28 12:40:25 dog [Reply | View]
  
  

  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?

• I have nothing against closure but I don't like the syntax that has been choosen for the closure
  2006-08-25 08:25:04 vbrabant [Reply | View]
  
  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.
• I have nothing against closure but I don't like the syntax that has been choosen for the closure
  2006-08-26 03:14:45 xmirog [Reply | View]
  
  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.

• while we're at it,
  2006-08-25 08:19:53 ilazarte [Reply | View]
  
  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.
• while we're at it,
  2006-08-25 08:53:24 alski [Reply | View]
  
  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...

• Closures yes. Function types no.
  2006-08-25 08:09:21 tjpalmer [Reply | View]
  
  

  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.

• About time & great suggestion
  2006-08-25 07:14:50 eirikma [Reply | View]
  
  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.

• Hard choice
  2006-08-25 06:03:00 larswestergren [Reply | View]
  
  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.

• About time!
  2006-08-25 05:18:27 ctreber [Reply | View]