river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: River-436 - need some explanation of preferred class provider
Date Fri, 07 Mar 2014 19:57:19 GMT

Doesn’t look like there’s any magic.  I performed a test, which can be seen at

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.


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

View raw message