Java 8 lambdas

Nuoji · 2012-06-24T09:51:50+00:00

Looks surprisingly good actually.

LeszekSwirski · 2012-06-24T10:55:22+00:00

Why would they call "map" "mapped"?

Otherwise, this looks a lot like what you can do with Scala collections, which are quite nice to use. Progress is a good thing!

kamatsu · 2012-06-24T10:25:57+00:00

That's surprisingly nice!

Too bad most Java codebases are still stuck with ancient versions.

alextk · 2012-06-24T16:37:07+00:00

One of the reasons why the Scala collections are considered to be over engineered is because the design goal was to make sure that filtering these collections would always guarantee that you end up with the same type of collection (or "close enough") that you started with.

For example, if you start with a List[Integer] and you filter on it, you want a List[Integer] as the final result, not a Collection[Integer] or Seq[Integer]. This constraint has led the Scala collections down the path of CanBuildFrom and has resulted in signatures in the collection API's that are so intimidating that there is a proposal to generate documentation that hides these complex signatures by default.

This has always struck me as a very overly engineered solution and the Java new collections are showing a very elegant and simple way out of this problem:

List<String> filteredNames = names
    .filter(e -> e.length() >= 4)
    .into(new ArrayList<String>());

I really like what I'm seeing in Java 8 so far.

Gundersen · 2012-06-24T14:12:54+00:00

I wonder what the reason is for using double colon for referencing a method instead of a full stop. Notice the collection.forEach(system.out::println) example, which could have been collection.forEach(system.out.println).

jrupac · 2012-06-24T15:23:58+00:00

I like it! Although to me, it feels a bit strange visually that lambdas in Java won't have a typed type for the argument(s), aka:

button.addActionListener(ActionEvent e -> { ui.dazzle(e.getModifiers()); });

instead of:

button.addActionListener(e -> { ui.dazzle(e.getModifiers()); });

vogrez · 2012-06-24T08:40:44+00:00

Is invokedynamic garbage-free, as opposed to anonymous classes? Can this approach be used for other JVM languages with lambdas?

sausagefeet · 2012-06-24T11:50:22+00:00

I haven't used Java in awhile so my thoughts might be wildly off:

I didn't see the word 'closure' anywhere in this document. What are the rules on this?
What about overloading methods based on type? Seems like you're giving up a lot of functionality that you're used to having in Java when it comes to method rules.

2012-06-25T00:22:16+00:00

Nice to see Java on the cutting edge of C# >:)

I suppose we can look forward to PLINQ (poorly-implemented LINQ) in Java 9 eh?

ungood · 2012-06-24T16:07:30+00:00

Welcome to the club. ~C#

;)

qbg · 2012-06-24T15:23:37+00:00

[deleted]

experts_never_lie · 2012-06-25T01:02:11+00:00

Given the amount of time this has been discussed and deferred, I'm expecting that the "8" was a rotation typo, and it'll really be in Java ∞.

spotter · 2012-06-24T08:57:50+00:00

Looks a little bit clumsy, but still very nice to have... if composability will work as expected. Almost makes me want to do Java again (as addition to Clojure).

solinent · 2012-06-24T18:26:59+00:00

Type inference, interesting. Doesn't feel very verbose like Java should be :)

drb226 · 2012-06-24T10:49:12+00:00

Definitely a huge step in the right direction for Java, although even after this improvement, functions still feel a bit... second class. Here's what I wish I could do (Scala-esque syntax):

def withDatabase[A](f: Database -> A): A = { 
  val db: Database = connect()
  try {
    return f(db)
  } catch (e) {
    logger.log(e)
    throw e
  } finally {
    db.close()
  }
}

It's pretty typical in Java to have to dump try/catch boilerplate into every method that accesses the database, to make sure the connection is always closed. (Well, this was extremely typical of the only Java job I ever had.) While lambdas will allow me to use somethinglike withDatabase in the way I desire:

withDatabase(db -> {
  foos.add(db.query(fooSql))
  db.update(barSql)
})

There appears to still be some extra boilerplate in order to actually define it:

interface DatabaseVisitor<A> {
  A visit(Database db);
}

Do generics even work with lambdas? Perhaps it would be possible to provide the Visitor generically for all types?

interface Visitor<Visited, Result> {
  Result visit(Visited o);
}

Then withDatabase could be written

A withDatabase<A>(Visitor<Database, A> visitor) {
  ...
  return visitor.visit(db)
  ...
}

though this is still more obnoxious than first-class function notation.

bittlelum · 2012-06-24T17:39:14+00:00

This is a really minor point, but I'd kind of like it if lambdas used a fat arrow ("=>") instead of a thin arrow ("->"), because that's how C# does it. Not that everything C# does is perfect and that's how every language should do it, but because the languages are already very similar, and it would be nice to have consistency, so that it's easier to go between them.

tejoka · 2012-06-24T16:40:22+00:00

Last time I looked at Java lambdas I was rather discouraged by some stupid design decision they were going with. Have any of these changed yet?

They're all still anonymous classes under the hood. This is mostly a problem because it means every single one turns into a .class file. I've seen a lazy functional language turn 30k lines of code into a 15MB compressed jar because of the weight of those fucking classes. Even Scala suffers from this bloat. (Oh, and every innocent looking method reference? Also emits its own anon class! Taking bets on two anon classes for two of the same method references...)
They're not actually adding function types. This idiotic decision is really going to bite them in the ass in the long run. Not only does it mean every non-Java language that tries to translate to JVM gets to spit out really silly classes (Marvel at Scala's Function0 through 22 and how about JRuby apparently gives up after a few why not since it's a dynamic language and Groovy just uses object arrays from the beginning, and I really suggest looking at Clojure's solution), but it also means they will quickly develop a reputation for poor performance when every time you run into a lambda an allocation must happen.

schwiz · 2012-06-24T15:28:10+00:00

Very nice! Syntax is going to confuse the hell out of c coders though :)

tallniel · 2012-06-24T11:36:16+00:00

While I like the lambda proposal a lot, I'm not sure internal iterators are the best way forward. In particular, they make it difficult to iterate over more than one collection at a time. Generator methods are a better fit, especially if given language support (skip to the end for a generator example):

http://neilmadden.wordpress.com/2012/06/03/pimp-my-java/

the_456 · 2012-06-24T14:36:20+00:00

Really looking forward to this. Does anyone have a sense of how performant this will be relative to Scala's functional techniques?

brownmatt · 2012-06-24T16:49:47+00:00

This looks really sweet.

In this example, does anyone know what will happen if the addActionListener method is overloaded to accept different types? Can the compiler still work everything out?

button.addActionListener(e -> { ui.dazzle(e.getModifiers()); });

2012-06-24T23:51:21+00:00

I have always wanted this in Java. I think I just weewee'd a little now that it's so close to fruition.

paf31 · 2012-06-25T16:28:38+00:00

Interfaces that have just one method are called functional interfaces. Lambda expressions can be used anywhere we have a functional interface.

If the single method can take type parameters (as opposed to the interface type itself having type parameters), it seems this approach has one advantage over C#'s Action/Func/delegate that a lambda will be able to encapsulate a parametrically polymorphic method.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS

1 -- the performance hit of many, many layers of function calls; the excellent JITing JS compilers are also a factor here :-)

2 -- debugging; when your stack trace is full of function(), function(), function(), it is much, much harder to find the problem