Doesn’t look like there’s any magic. I performed a test, which can be seen at https://github.com/trasukg/LambdaSerialization
Basically, I serialize a lambda function in one project, then copy it into another project, so that the original class is not in the class path of the new project. Sure enough, we get a ClassNotFoundException on the attempt to deserialize. I think what Goetz means when he says “the meta factory lazily creates the byte code..” is that the way the lambda is instantiated is subject to overwriting a run time, however the code contained _within_ the lambda function remains resident in the class that defines it. So, I think it’s fair to say that codebase annotation and dynamic loading _will_ be required on a lambda function. More critically, if a client were to serialize a lambda function, it would have to make its implementation jar available. In other words, the client would still be subject to a division of its code into a separate “proxy” or “download” layer. And this “-proxy.jar” has to be subject to the same type of versioning that a service’s “-proxy.jar” needs to follow, which is why caching dynamically loaded code has always been a problem. Cheers, Greg Trasuk. On Mar 7, 2014, at 2:21 PM, Tom Hobbs <tvho...@googlemail.com> wrote: > 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 >>> >>> >>
