Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <1394216496.9471.11.camel@Nokia-N900>
References: <5313816B.9030703@xpro.biz>
	<49788342.RIv7B4Njyi@mkleczek-laptop>
	<1394099773.8503.6.camel@Nokia-N900>
	<8554390.GqDjNHv7qN@mkleczek-laptop>
	<1394183922.8503.24.camel@Nokia-N900>
	<C1203060-74B6-4161-9EAB-272295B07158@stratuscom.com>
	<1394216496.9471.11.camel@Nokia-N900>
Date: Fri, 7 Mar 2014 19:55:24 +0100
Message-ID: 
 <CAL2DxM6B46KBs-LTxUmXYNEL5QC_zDgVbBXctqT49DAWxsa-jg@mail.gmail.com>
Subject: Re: River-436 - need some explanation of preferred class provider
From: =?UTF-8?B?TWljaGHFgiBLxYJlY3plaw==?= <michal.kleczek@xpro.biz>
To: dev@river.apache.org
Content-Type: multipart/alternative; boundary=001a1133c9aae59f9704f408cbbf

--001a1133c9aae59f9704f408cbbf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C5=82(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 t=
he
> > > > 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=E2=80=A6are 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=E2=80=99t tried it in code,
> > but from reading JSR335, I get the impression that Java lambdas are not
> > LISP lambdas, i.e. it=E2=80=99s not so much dynamic byte code generatio=
n as
> > syntactic sugar that avoids the need to define an interface for what is
> > effectively an inner class (it=E2=80=99s not quite an inner class, as i=
t doesn=E2=80=99t
> > redefine =E2=80=98this=E2=80=99, but is otherwise pretty close.   For e=
xample, there
> > aren=E2=80=99t real closures; local variables can only be captured if t=
hey 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=E2=80=99s no need, for example to down=
load an
> > implementation class for an object that is directly exported - you only
> > really need the service interface to be available locally.   Having sai=
d
> > that, I think most of us are in the habit of treating =E2=80=9Cjava.rmi=
.Remote=E2=80=9D
> > as an implementation detail that shouldn=E2=80=99t be reflected in the =
service
> > interface, so for instance, we=E2=80=99ll have a service interface, =E2=
=80=9CHello=E2=80=9D
> > which doesn=E2=80=99t extend Remote, and whose methods may throw IOExce=
ption,
> > and then we=E2=80=99ll have a proxy interface (which goes into the =E2=
=80=98-dl=E2=80=99 or in
> > Dennis=E2=80=99 terms =E2=80=98-proxy=E2=80=99 jar) called HelloRemote =
that extends Hello and
> > Remote.   The client will download HelloRemote from the codebase
> > annotation.
> >
> > In any case, I don=E2=80=99t think Java lambdas are the magic bullet yo=
u=E2=80=99re
> > thinking they are.   I=E2=80=99d be happy to be proven wrong though, be=
cause what
> > you=E2=80=99re talking about would be pretty cool.
> >
> >
> > Cheers,
> >
> > Greg Trasuk
>
>

--001a1133c9aae59f9704f408cbbf--