river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River-436 - need some explanation of preferred class provider
Date Sat, 08 Mar 2014 08:04:53 GMT
Ok, I've looked into the latest code, previously a lambda was only Serializable if explicitly
defined, now it looks like all lambda's are and the expert group has decided to make lambda
serialization like inner classes so users know what to expect.

I would have much preferred limited Serialization that's simple, rather than everything's
Serializable but broken.

So you're right, magic gone, at least for distributed programming.

I'll do some more investigation, but this looks bleak.

Regards,

Peter.

----- Original message -----
> 
> 
> 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 <tvhobbs@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.kleczek@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" <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