7 ms·
Java 8 lambda syntax decided - same as C# and Scala
- fosk 15y agoFinally 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 15y agoGroupthink: 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 15y ago"Mistakes will be made, but that's good because it means decisions are being made." -- Steve Jobs
- shriphani 15y agoHow is this a mistake ?
- yzhengyu 15y agoErm, 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.
- revertts 15y agoI think stating it that way trivializes the amount of work that _has_ gone into lambdas. There's been a lot of other, more fundamental things discussed over that 2-3 year period about their implementation; way more than syntax.
- wanorris 15y agoWhat in particular? (Java isn't my primary language, so I haven't been following this.) Do you mean about how lambdas are implemented from a bytecode standpoint, or other types of issues?
- bermanoid 15y agoYes, to some extent there were debates about how the implementation would work, but also about how they would interact with all the various other features of Java, most of which were not constructed with lambdas in mind: generics, exceptions, inheritance, and so on, not to mention lots of fights over the syntax. For instance, there was a long battle over whether () would be enough to invoke a lambda, or whether some sort of apply() or invoke() or .() method would be required, and a lot of the problems with () come down to differences between the way fields and methods are inherited in Java, esp. w.r.t. shadowing. I don't even know how it all came down, but it gets nasty, a lot of this stuff just wasn't designed with lambdas in mind.
- MatthewPhillips 15y agoLambdas are a lot of fun on C#. new Thread( => { doStuff(); }).Start();
- onedognight 15y agoAccording to the grammar int the OP, you need ()'s, no? new Thread(() => { doStuff(); }).Start(); Or can they be elided in C# or Scala?
- gnuvince 15y agoThe empty () are required in Scala. Don't know about C#.
- latch 15y agoyes, they are in C# as well.
- swax 15y agoActually for just that example you don't need any of it. new Thread(doStuff).Start();
- MatthewPhillips 15y agonah, it would have to be new Thread(new ThreadStart(doStuff)).Start();
- jeffz 15y agoSorry, but since C# 2.0 we could just write "new Thread(DoStruff)" or "SomeDelegate del = SomeMethod".
- politician 15y agoI can't resist, so, public static class ActionExtensions { public static void InvokeAsync(this Action<object> target, object context) { new Thread(obj => target(obj)).Start(context); } } ((Action<object>) (Console.WriteLine)).InvokeAsync("Hello, World");
- BDFL_Xenu 15y agoI 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?
- spullara 15y agoThe single abstract method interface type of a lambda will be inferred by its declaration site.
- umjames 15y agoWill they be full closures and remember the state of objects in scope?
- BDFL_Xenu 15y agoIf they will be based on anonymous inner classes, then yes, they'll capture the variables from the surrounding scope. Those variables however will be 'final', which means that you can't re-assign them, even if their values are still liable to side-effects (e.g. setting fields, mutating collections, etc).
- spullara 15y agoThey are not based on anonymous inner classes (the implementation is likely to be much different) but they have the same restrictions as BDFFL_Xenu described.
- jinushaun 15y agoGood. The lambda syntax in C# rocks and is a natural fit for Java considering the origin of C#.
- jpitz 15y agoObject Pascal?
- thurn 15y agoExcellent 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 15y agoNota 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.
- calebmpeterson 15y agotry { // for a really long time } finally { // made a decision }
- Locke1689 15y agotry { /* for a really long time */ } finally { /* made a decision */ }
- calebmpeterson 15y agoPlease tell me how you got it formatted like code. I tried a block quote and got italics instead.
- koenigdavidmj 15y agoIndent by four spaces.
- keiferski 15y agoI think two spaces are enough
- zokier 15y agotry { /* thinking for a really long time */ } catch (TimeoutException ex) { /* copy from C# */ }
- vorg 15y agoThere'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.
- mwsherman 15y agoOP mentions that there were other ideas in the running. Anyone know what they were?
- zmmmmm 15y agoNice 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 15y agoIt's also a shame they haven't done so with other features -- like getting rid of checked exceptions.
- reinhardt 15y agoGetting rid of something is always harder than adding it later.
- loup-vaillant 15y agoI don't think this is the case here. The question isn't whether you "add" or "remove" something. The question is whether the old programs will still work or not. If I understand checked exceptions correctly, removing them will only allow more programs to compile. The old ones will still be valid as their (now optional) try-catch/finally blocks won't go anywhere.
- Torn 15y agothrows RuntimeException and try / catch around RuntimeException would still be valid, so I can't see how changing all checked exceptions to runtime shouldn't affect the flow of the code. If users wanted to they could declare 'throws TheirParticularRuntime' all the way up the stack and it would work like checked exceptions, right?
- xtracto 15y agoCan you expand on why would you like to get rid of checked exceptions?
- zokier 15y agoAny details on variable capturing from outer scope? The same as C# (apparently capture all variables?)?
- zbowling 15y agoyes, closures are implied. lambda's are almost useless without closures being included.
- artsrc 15y agoI 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.
- zokier 15y agoI'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 15y agoPresumably it would work identically to inner classes (only captures final variables, so value/reference doesn't matter).