This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
I will admit that I have not read the JSR335. Just want to have a quick introduction of Lambda Expressions. Is it something similar to or based on Lambda Calculus?
The term does come from the Lambda Calculus, which was the inspiration for LISP. A lambda expression is an anonymous function. Think of a case when you created an anonymous class in order to perform a method contained in it.
If you're familiar with Delegates in C#, then you can think of this JSR as Java's initiative to do likewise.
Wikipedia wrote: Lambda calculus (also written as λ-calculus or called "the lambda calculus") is a formal system in mathematical logic for expressing computation by way of variable binding and substitution.
On the similar lines Lambda Expressions in Java allow you to capture variables declared outside the scope of the lambda expression assuming the variable is eventually final i.e though the variable is not declared as final its value is not updated before its used in the Lambda expression- this is also called as a closure.
There is a problem associated with Anonymous Inner classes that they can only refer to variables outside its scope which are declared as final. The Lambda expressions can be used to overcome this restriction.
All those anonymous inner class instantiation of Single Abstract Method (SAM) classes which would be called as Functional Interfaces in JSR-335 can be replaced with Lambda expressions. The type inference mechanism would convert the corresponding Lambda expression into an instance of that SAM class.
For Example:
but with JSR 335 in Java 8 one could write the above code as:
This is just scratching the surface of JSR 335. The collections API is being enhanced with new APIs which allows you to perform operations like: arrayList.filter(lambda1).map(lambda2).into(newArrayList).
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.
I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?
Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.
Stas,
You are making up your mind just after a glance. Just give sometime to understand the philosophy behind the language, try to build few things with it and then you would be in a better position to judge a language.
Stas Sokolov wrote:Is there any Java framework / JVM extension that already in one way or another mimics this syntax ?
You can have a look at the JVM based language called Scala.
It looks not so good. Syntax is unreadable. Somebody who decided to use a class body to define lines of constructor between different methods was just insane. This one Kotlin is a little bit easier and structural but I still like to stick with all good Java just using the same nice things that were defined in Project Coin and then Oracle took them off.
Stas,
You are making up your mind just after a glance. Just give sometime to understand the philosophy behind the language, try to build few things with it and then you would be in a better position to judge a language.
I did my research comparing Java and Scala a while ago and I even wrote some performance tests comparing Java and Scala. Java wins because it support primitive arrays when in Scala every primitive type is an object.
Rick Goff wrote:I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?
Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.
Any Scala code premier looks like an ugly PERL script. It might be shorter than Java in some way, but I would give +1 for this and -10 for readability.
Rick Goff wrote:I'm not sure it's due diligence for you to glance at a language Martin Odersky and others took years to produce, and declare it unreadable. What else is unreadable to you? Russian? Mandarin?
Sorry if that's snarky. More constructively, I suggest you post a sample of "unreadable" Scala and see if we can work out what it means.
Any Scala code premier looks like an ugly PERL script. It might be shorter than Java in some way, but I would give +1 for this and -10 for readability.
2. The "object" keyword creates a singleton, which is appropriate to this case. "primes" is the name of this object. "extends Application" is a poorly chosen but valid way to mark this object as runnable.
3. def means "I'm defining a function." (n: Int) means "take an argument which must be of Int type." (2 until n) should be (2 until n/2) but in any case it means "start at 2 and proceed as far as n. "
forall means "if the predicate on my right is true for every item (n) in the iterator on my left."
(n % _ != 0) means "n divided by anything does not have a remainder of 0."
isPrime(n) returns the boolean resut of the forall test.
4. for every number between 1 and 100, test it using the function we defined on line 2. If true, print the value and a carriage return.
Milan Sutaria
Ranch Hand
Joined: Jul 10, 2008
Posts: 118
posted
0
wow that was good to know upcoming features in Java. Looking forward to give a SCJP 8 sample test before go live.
SCJP 6 83%
Working on SCWCD/OCPJWCD
Hendra Kurniawan
Ranch Hand
Joined: Jan 31, 2011
Posts: 239
posted
0
AFAIK, lambda expressions exist only in .Net technology. Does this mean Java will also introduce this feature in the next release?
Hendra Kurniawan wrote:AFAIK, lambda expressions exist only in .Net technology. Does this mean Java will also introduce this feature in the next release?
Closures were left out of Java initially more because of time pressures than anything else. Closures, as a concept, are tried and true - well past the days of being PhD topics. The arguments are in the details, not the broad concepts. In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues. But as is normal in so many design issues, the simplifications didn't really solve any problems, they just moved them. We should have gone all the way back then
Here he's talking about closures rather than lambda expressions, but the two are pretty similar. A true closure would also be able to access local non-final variables, which lambdas cannot. A few years ago many people in the Java community were using "closure" indiscriminately for things that weren't really closures; nowadays "lambda expression" is more common.
Speaking for myself, I want lambdas in an object-oriented language like Java because:
* They are visually cleaner and more concise than anonymous classes.
* Rather than saying we need to create an object to contain a function, we take the attitude that a function is an object.
* They allow us to reduce a lot of boilerplate code in Java through library additions rather than requiring language changes. E.g. the enhanced for loop and try-with-resources would have been easily implemented with library code, not language changes, if we'd had lambdas in the first place.
* Most of the other newer languages that compete with Java have lambdas (or something like them) already: C#, Ruby, Groovy, Scala, Clojure, Kotlin, Ceylon, and more
So, to summarize, does it mean that Java is going to adopt Groovy syntax?
SCJP, SCJD, SCEA
Mike Simmons
Ranch Hand
Joined: Mar 05, 2008
Posts: 2782
2
posted
0
Sort of. The idea of lambdas is present in a bunch of other languages, not just Groovy. And there's no indication Java is adopting any other Groovy syntax. But adding lambdas to Java can be seen as a big move in the direction of Groovy (and Ruby and Scala and C# and JavaScript and heaps of others).
It's tempting to someone who has always thought of programming from an "object-oriented" perspective to conquer their dissidence about new features by analogizing them to tools they recognize. If you're really interested in the value of Lambda expressions, you need to stop thinking like a Java programmer (exclusively), and start thinking like a problem solver who values concurrency and parallelism.
Ask yourself this: why has Lisp survived the entire first 55 year period of the history of programming? Maybe read a short intro to Lisp or Haskell, and see if you can find the appeal.
As Java programmers, we have conceded the inevitability of shared mutable state. What if we didn't?
0
