I'm certainly no expert, but my understanding is that the so called "meta factory" lazily creates the byte code to service the lambda during first call. So you are correct, they are not compiled to anon inner classes, they do end up as private methods, but indy creates uses this factory as a receipe for how to create the lambda, relying on the runtime to follow that recipe as it sees fit.
>From your link. "Instead of generating bytecode to create the object that implements the lambda expression (such as calling a constructor for an inner class), we describe a recipe for constructing the lambda, and delegate the actual construction to the language runtime. That recipe is encoded in the static and dynamic argument lists of an invokedynamic instruction. The use of invokedynamic lets us defer the selection of a translation strategy until run time." They can also relinked/created/etc should subsequent calls to them be made with different argument types. [2] is also an interesting read. [1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html [2] http://www.slideshare.net/jaxlondon2012/lambda-a-peek-under-the-hood-brian-goetz On Fri, Mar 7, 2014 at 6:55 PM, Michał Kłeczek <michal.klec...@xpro.biz>wrote: > Although lambdas are not compiled to anonymous classes the code IS NOT > generated at runtime. They end up as methods and bound in runtime using > invokeDynamic. > > See: > http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html > > Regards > 7 mar 2014 19:22 "Peter" <j...@zeus.net.au> napisał(a): > > > ----- Original message ----- > > > > > > On Mar 7, 2014, at 4:18 AM, Peter <j...@zeus.net.au> wrote: > > > > > > > > > > > > Also... Could you elaborate more on code dynamically generated at > the > > > > > server and how does it differ from code downloading? > > > > > > > > Bytecode for lambda expressions is generated at runtime by the jvm, > > > > lambda's use a single serialization proxy class, necessary > > > > implementation bytecode is dynamically compiled upon deserialisation. > > > > > > > > How lambdas change > > > > > anything (since lambdas are only Java _language_ level > > constructs I > > > > > really don't see how). > > > > > > > > Dynamically compiled code doesn't need a codebase annotation, it's > > > > created as needed and it's visibility is correct for each use case, > > > > it's very specific, implementing a public interface and interacting > > > > through this. > > > > > > > > > > Um…are you sure about that? > > > > Yes, 100%, they're definitely not syntactic sugar, it does serialize the > > final field arguments to the lambda expression, so if these are smart > > proxy's, yes it will need to marshall those arguments but no, it's not an > > internal anonymous class and doesn't need to send its enclosing class. > > > > Go have a look at Brian Goetz's presentations, check out some code and > > read the development mail lists, it's pretty cool. > > > > Cheers, > > > > Peter. > > > > I confess that I haven’t tried it in code, > > > but from reading JSR335, I get the impression that Java lambdas are not > > > LISP lambdas, i.e. it’s not so much dynamic byte code generation as > > > syntactic sugar that avoids the need to define an interface for what is > > > effectively an inner class (it’s not quite an inner class, as it > doesn’t > > > redefine ‘this’, but is otherwise pretty close. For example, there > > > aren’t real closures; local variables can only be captured if they are > > > effectively final). There also seems to be a lot of compile-time type > > > inference going on. I suspect that passing a lambda as a marshalled > > > object will still require the containing class to be loaded. > > > > > > Now, dynamic proxies are a different story, and JERI already uses the > > > dynamic proxy mechanism. There’s no need, for example to download an > > > implementation class for an object that is directly exported - you only > > > really need the service interface to be available locally. Having > said > > > that, I think most of us are in the habit of treating “java.rmi.Remote” > > > as an implementation detail that shouldn’t be reflected in the service > > > interface, so for instance, we’ll have a service interface, “Hello” > > > which doesn’t extend Remote, and whose methods may throw IOException, > > > and then we’ll have a proxy interface (which goes into the ‘-dl’ or in > > > Dennis’ terms ‘-proxy’ jar) called HelloRemote that extends Hello and > > > Remote. The client will download HelloRemote from the codebase > > > annotation. > > > > > > In any case, I don’t think Java lambdas are the magic bullet you’re > > > thinking they are. I’d be happy to be proven wrong though, because > what > > > you’re talking about would be pretty cool. > > > > > > > > > Cheers, > > > > > > Greg Trasuk > > > > >
