Java 8 lambda syntax decided - same as C# and Scala

http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html

by tomeast • 15 years ago

169 78 15 years ago

mail.openjdk.java.net

fosk• 15 years ago

Finally a decision was made. The decisional process is too slow, this is why Java in 2011 still misses those features that languages like C# already support since years.

Rickasaurus• 15 years ago

Groupthink: I think we should have a vote on if we're going to vote on when we're going to set a deadline for deciding on lambda syntax.

shawndumas• 15 years ago

"Mistakes will be made, but that's good because it means decisions are being made." -- Steve Jobs

shriphani• 15 years ago

How is this a mistake ?

yzhengyu• 15 years ago

Erm, its not?. Shawndumas was just pointing out that a decision was finally made. They were grappling over the syntax for over two three years.

Now they will just need to grapple over with what kind of scoping that Java's lambdas will have.

MatthewPhillips2• 15 years ago

Lambdas are a lot of fun on C#.

new Thread( => { doStuff(); }).Start();

onedognight• 15 years ago

According to the grammar int the OP, you need ()'s, no?

  new Thread(() => { doStuff(); }).Start();

Or can they be elided in C# or Scala?

gnuvince• 15 years ago

The empty () are required in Scala. Don't know about C#.

swax• 15 years ago

Actually for just that example you don't need any of it. new Thread(doStuff).Start();

linuxhansl• 15 years ago

Big deal:

    new Thread(new Runnable() { public void run() {doStuff();} }).start();

ppog• 15 years ago

But for a small function (which a lambda typically is), the syntactic overhead of "new Runnable() { public void run()" swamps the actual logic. When I read this version, it's hard for my eyes to find what work is actually being done because there are so many braces and brackets and words. The big deal of lambda syntax is that it lets you focus on the code that does the work (the doStuff) instead of the adapter (the "new Runnable() { public void run()") that the library needs around that code.

moomin• 15 years ago

Cool. Now how about

companies .Where(c => c.Name.StartsWith("A")) .GroupBy(c => c.Sector, c => c.ProfitAndLoss) .Select(g => new {Sector = g.Key, Profitability = g.Sum()}

Closures are massively more compact than running around with inner classes for everything.

BDFL_Xenu2• 15 years ago

I see that the proposed lambda expressions can omit type annotations on the parameters. Does that mean that Java 8 will have at least some limited form of type inference?

spullara2• 15 years ago

The single abstract method interface type of a lambda will be inferred by its declaration site.

umjames• 15 years ago

Will they be full closures and remember the state of objects in scope?

jinushaun• 15 years ago

Good. The lambda syntax in C# rocks and is a natural fit for Java considering the origin of C#.

jpitz• 15 years ago

Object Pascal?

thurn• 15 years ago

Excellent to have this finally resolved. I'm sad to not see something a little closer to the ruby block syntax like in some of the early proposals, though. Special syntax for lambdas as the last argument to a function lets you write very readable code for a host of useful cases.

raganwald• 15 years ago

Nota Bene: A Ruby Block is not the same thing as a Ruby Lambda, although conversion between them is easy. Yielding to a block has somewhat different semantics than calling a lambda, especially with respect to non-local return.

calebmpeterson2• 15 years ago

try { // for a really long time } finally { // made a decision }

Locke1689• 15 years ago

  try { /* for a really long time */ } finally { /* made a decision */ }

calebmpeterson2• 15 years ago

Please tell me how you got it formatted like code. I tried a block quote and got italics instead.

zokier3• 15 years ago

  try { /* thinking for a really long time */ } catch (TimeoutException ex) { /* copy from C# */ }

vorg5• 15 years ago

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g

    try{
      //for a short time only to decide
    }

But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g

    try{
      //for a short time to decide
    }finally{}

Because I had used these standalone try-statements a lot, I had to go thru all my code and add empty finally statements to them all.

Scala, on the other hand, still allows standalone try-statements. And Scala and C# also have a better closure syntax than that language, and are more worthy to be copied by Java 8.

ddlatham• 15 years ago

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

jmillikin• 15 years ago

  But one of its despots, five years after the language was
  first released, changed the syntax to make a catch or
  finally clause compulsory, e.g

Are you the person who believes the Groovy developers are personally working to invalidate your web tutorials so they can discredit your fork of the language?

Lest HN think I'm being ungenerous, please read http://groovy.codeplex.com/wikipage?title=Blog01 , which features similar language regarding "despots".

  Of course, Groovy also differentiates itself from Guava
  by having a dedicated language syntax, which is no doubt
  why the cartel don't want to standardize it. If it was
  standardized, they couldn't make some random blogger's
  sample code stop working by suddenly requiring all
  try-statements to have an empty finally clause.

yock• 15 years ago

Perhaps you can educate me on your better reasoning, but the only purpose I can see for an empty try block is to limit the scope of variables in a method. Quite frankly, if you find yourself in need of artificially limiting the scope of variables in a method, you've probably done too much in the method and need to refactor.

Try block are for just that, trying something you know ahead of time might fail. There's no point in using the try paradigm if you don't also intend to handle the expected failure.

mwsherman• 15 years ago

OP mentions that there were other ideas in the running. Anyone know what they were?

zmmmmm• 15 years ago

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice.

From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

bad_user• 15 years ago

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

reinhardt• 15 years ago

Getting rid of something is always harder than adding it later.

xtracto• 15 years ago

Can you expand on why would you like to get rid of checked exceptions?

wlievens• 15 years ago

Some people like them, you know.

vetler• 15 years ago

At least Java 7 has multi-catch, i.e.

  catch (FirstException | SecondException ex)

wcoenen• 15 years ago

I think checked exceptions are just ahead of their time. They make sense when you statically check your code against contracts, which is why they showed up again in the spec# research project. http://en.wikipedia.org/wiki/Spec_Sharp

paperwork• 15 years ago

Why are you opposed to checked exceptions?

Frankly this is one complaint about java I have never understood. I, myself, have missed checked exceptions in C# when I have had to port Java code to C#.

zokier3• 15 years ago

Any details on variable capturing from outer scope? The same as C# (apparently capture all variables?)?

zbowling• 15 years ago

yes, closures are implied. lambda's are almost useless without closures being included.

artsrc• 15 years ago

I think the difference between capturing values at call time and full closures only matters if you are mutating variables, which my closures rarely do, since my code is fairly functional'ish, so for me it does not matter.

zokier3• 15 years ago

I'm more familiar with C++ lambdas, and in those you must specify how you will capture variables (no capturing, by reference, by value, or some mix of those).

colanderman• 15 years ago

Presumably it would work identically to inner classes (only captures final variables, so value/reference doesn't matter).

Java 8 lambda syntax decided - same as C# and Scala

Related Stories