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 > >
