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 14:32:04 GMT

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?  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
View raw message