Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news2.arglkargh.de!news.swapon.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= Newsgroups: comp.lang.java.programmer Subject: Re: Java 8 closures vs. anonymous inner classes Date: Wed, 04 Dec 2013 22:27:49 +0200 Lines: 43 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.dfncis.de /9fUHLvNt3Uv/4cs1xpTiwfyO3zPA7tU7wwRlRzKoYgzhHMqVNm0civI4D Cancel-Lock: sha1:aBNCUQxVWJdBNoMAf97foY5KzbY= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:26729 Am 04.12.2013 21:07, schrieb Sebastian: > Someone made a passing comment in another thread to the effect that Java > 8 lambdas ("closures") were nothing but syntactic sugar for (anonymous) > inner classes. Here are a three differences: > > 1) lambdas can only instantiate "functional" (single abstract method) > interfaces so? > 2) lambdas have different scoping rules ("this" means different things) so? > 3) lambdas perform better due to the use of the invokedynamic JVM > instruction. Type representation, instance creation, and invocation > strategy are decided at runtime. This offers optimization potentials, > because evaluating a lambda expression need not create a new instance > each time. There could be „shared lambdas“ through use of a constant > static method in a constant pool, needing no new class and/or new object. When I was digging through the byte code, invokedynamic was simply used to invoke some fancy method that would basically encapsulate the creation of the lambda object (which then is nothing more than an instance of some class that implements the interface in question). So obviously, all some magic happens here - but the magic is pretty much limited to some a bunch of things that may likely speedup the creation of lambda objects. My point being: after creating the object representing the lambda object, everything is as it was before, even the performance I guess. I suspect, one could easily have achieved the speed up (if there is any) by re-using instances of some inner class instead of using invokedynamic plus some magic in the JVM. > This is quite a bit more than what I'd call "syntactic sugar". Certainly. And the implementation of it all is probably pretty ugly too! Regards, Sven