river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: River-436 - need some explanation of preferred class provider
Date Fri, 07 Mar 2014 18:55:24 GMT
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" <jini@zeus.net.au> napisał(a):

> ----- Original message -----
> >
> > On Mar 7, 2014, at 4:18 AM, Peter <jini@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message