@EliI have never used closures before but I can't see anything about it that could cause bugs. Since JavaScript is very different from Java, closures may have some error-prone syntax. However, I see closures as a way to type less and to write more dynamic code.

That's an oversimplified example, but basically doSomeCrap will get called on array[array.length-1] array.length times. That's because the way a js closure works is that the most recent assignment to the value it finds will be used. The correct way of doing the above is binding i into the function as a parameter - thereby not using closures. The above is pretty obvious, but if you have a complicated group of callbacks that happen through like 3 different classes and two of them just happen to both define a variable of the same name, you can get the wrong variable being used.

Oh well if there are multiple variables of the same name in different classes and the coder gets them confused, it is the coder's fault I do understand your point but since I have yet to try to closures, I still assume I would be easily able to use them without being confused about the order of execution.

I disagree with a lot of people here. Java is going to become so complicated and remember what happened to C++ in the past... A modern language cannot get all "cool" features, choices have to be made and using several programming languages in a single project should not be a problem. Some languages are better to express of some kinds of things. If a single language tries to express at best anything, it can only become extremely complicated to use. Closures give a (contestable) comfort to some people but Java can live without it.

In my humble opinion, the syntax of Java should be frozen, the efforts should be concentrated on the APIs (repairing the existing APIs and adding new ones), the support of other languages on the same VM (not only scripting languages), the improvements of the deployment (applets and Java Web Start, plugin 3 with AWT-free fast launcher) and on the modularization (project JigSaw). I would prefer Oracle to help me to convince several Internet service providers to use Java in their ADSL TV boxes. We need Java everywhere, on consoles, on all smartphones including IPhones and Android (a DVM is not a real JVM).

Some C# programmers asked for closures in Java but I'm not sure that they are the people who use the most Java.

I've managed 30 years without needing closures. Now they're going to co-opt a few more ascii characters to do something that makes not a lot of sense and does even more trickery under the hood. Oh well, not much we can do about it.

I agree too and also prefer that the java syntax be kept simple and basic (as some here like to call it as a 'baby language' ). If they need all these extra things they should just pick up Scala and push it as an official jvm langauge. Scala has all the bells and whistles that one could hope for and is pretty compatible with normal Java too.

@gouessej - I'd generally agree with your list of priorities there and not adding stuff in for the sake of it. However, I'm coming around to this one, possibly for the same reason that Oracle did post-Sun, and in one word that is "concurrency". It's not that there are things impossible with Java's current syntax, but the amount of boilerplate code that can be removed is sometimes staggering. Java has always included (for the time) good multi-threading support, and I guess this helps further that.

The crappy thing about all this concurrency support is that the whole premise it appears to be based on - that is, unified memory architectures and multiple cores - is kind of crap compared to the infinitely more sensible Transputery way of doing things. IMHO it's going to set software engineering and hardware design back a decade

@gouessej - I'd generally agree with your list of priorities there and not adding stuff in for the sake of it. However, I'm coming around to this one, possibly for the same reason that Oracle did post-Sun, and in one word that is "concurrency". It's not that there are things impossible with Java's current syntax, but the amount of boilerplate code that can be removed is sometimes staggering. Java has always included (for the time) good multi-threading support, and I guess this helps further that.

What is the "cost" of closures on the "readability" of the source code? Do you have a precise example to illustrate your opinion? How are closures helpful in concurrency? The benefit of closures is very subjective, I can go on using anonymous classes containing a single method, complicating the syntax of the whole language can allow to avoid such boilerplate code but it can drive it more difficult to read.

It's a matter of taste, I find closures worse than anonymous classes containing a single method and do you know the secret of very long projects? When I know I'm going to see my girlfriend, I'm happy because she's pleasant and beautiful. It is exactly the same thing for my source code. I can work on the same project for years if I find the source code "pleasant and beautiful". nsigma finds closures better than anonymous classes containing a single method; in his case, closures are the way to go.

What is the "cost" of closures on the "readability" of the source code? Do you have a precise example to illustrate your opinion? How are closures helpful in concurrency? The benefit of closures is very subjective, I can go on using anonymous classes containing a single method, complicating the syntax of the whole language can allow to avoid such boilerplate code but it can drive it more difficult to read.

I did have a precise example, I just can't bloody find it now! Essentially it's to do with both fork/join (in 7) and also ParallelArray (in 8 I think). The example used 80% less code and was infinitely more understandable with closures. Parallelizing loop operations across data structures can benefit from closures, and seem much easier to understand without the boilerplate.

My absolute benchmark is less code and more legible - this example won me over! (and if I can ever find it again, I'll post a link).

I write a lot of JavaScript, and closures are easily one of it's best features. It is not that they will allow you to do anything new; it is that you can do the same in a more natural way. This means libraries will use closures more often, as they are much easier to wield then anonymous classes. Once your leveraging closures, there are lots of advantages.

The main one is that it allows libraries and frameworks to have more control over how they are used. It is very common to build a library, that manages some code, but has to be used in a specific way. As a result you can be expected to always call specific methods before performing certain tasks, or calling items in a specific order. Closures allow you to wrap up whatever task it is you are performing, then just hand it over, and have the library call it for you (at the right time).

For example asynchronously downloading multiple files, and running a task when they are all complete. Another example is being able to repopulate a cache, on the fly, when missing items are queried for. The task to generate those missing values can be stored inside the cache, using a closure. These are simpler to build if you can easily wrap up tasks to be passed in.

It can also allow you to build more efficient architectures. For example I once built a grid based data structure that partitioned sprites based on their class. It used custom data structures, but for simplicity, it was essentially a: Map<Integer, Map<Integer, Map<Class, List<Sprite>>>>. As you can imagine, iterating over that is not trivial, and a naive implementation requires using lots of iterator objects nested inside of each other. This iteration loop would build a list of Sprites to return, which would then be iterated over a second time by the caller. To improve this I built a version which used anonymous classes, and this allowed me to remove all of the iterator objects, the returned list, and the second bout of iteration. What is really important, is that is was simpler to optimize this using anonymous objects, then using a complex iterator solution. Closures make it more natural to build these solutions.

Finally writing a Swing UI is far too verbose. One of the issues is the large number of action listeners, and and closures would greatly reduce the amount of noise in your code.

I guess enough said for everyone who didn't need closures before wonders if he/she should care about this addition.

Also: It just seems to me that closures just allow stuff to be able to be compiled, but can very well fail at runtime. A thing java usually tries to avoid, and is praised for, in comparison with C++ for example.

I guess enough said for everyone who didn't need closures before wonders if he/she should care about this addition.

The last 30 years does not give a good guide to the next 30 years! Moore's Law is coming to an end, etc., etc.

People have stated Moore's Law has been coming to an end, repeatedly, for the last 30 years. We have at least another 10 years to go until we reach the physical barriers for miniaturizing transistors. By then we should have new methods for yielding larger, or layered chips, which will allow Moore's Law to continue for much longer.

I guess enough said for everyone who didn't need closures before wonders if he/she should care about this addition.

The last 30 years does not give a good guide to the next 30 years! Moore's Law is coming to an end, etc., etc.

People have stated Moore's Law has been coming to an end, repeatedly, for the last 30 years. We have at least another 10 years to go until we reach the physical barriers for miniaturizing transistors. By then we should have new methods for yielding larger, or layered chips, which will allow Moore's Law to continue for much longer.

To an end was perhaps too apocalyptic a way to phrase it , but I think the concept of what it means for us is changing. To quote that Oracle PDF I linked to

Quote

Chip designers have nowhere to go but parallel – Moore’s Law gives more cores, not faster cores

which, right or wrong, seems to be a key reason behind Oracle's decision to include closures in Java now.

I love how they show anonymous inner classes with no highlighting, then lambdas with highlighted text.

Lambdas murder readability when used extensively for loops. I curse every time I have to dig into C# where someone went balls out with lambdas unnecessarily. They probably do improve readability in other cases. I guess it will become just another thing to add to coding standards documents.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org