[gwt-contrib] dev tests failing locally?

[Colin Alworth]

I'm looking into fixing the javac.typemodel.JMethod creation to make it 
support static and default methods in Java8 interfaces so that generators 
(at least autobeans and requestfactory) can easily support categories 
without external classes (see 
https://github.com/gwtproject/gwt/issues/9289, I'm sure there are others). 
Along the way, I ran into a few unit tests that I apparently broke, and 
then discovered that these tests (at least locally) also consistently fail 
at current master. 

com.google.gwt.dev.resource.impl.ClassPathEntryTest
testResourceCreated
testResourceDeleted
testResourceRenamed

com.google.gwt.dev.resource.impl.ResourceAccumulatorTest
testDeleteFile
testMultipleListeners
testSymlinkInfiniteLoop
testSymlinks
testListensInNewDirectories
testRenameFile
testRenameDirectory
testRenameParentDirectory
testAddFile

My local tools dir is up to date, I'm running OS X 10.11.4, with ant 1.9.4 
and jdk 1.8.0_60-b27. Are these tests known to be broken, or is there 
something likely wrong with my setup? I can share the stacktraces 
themselves, but all of these seem to be related to filesystem access. Is 
there something funny about these?

I do see notes about ClassPathEntryTest failing (common.ant.xml and 
dev/BUILD), but ResourceAccumulatorTest doesn't seem to have notes about it 
- but, it isn't added to a test suite. Are these tests broken in ant, but 
not excluded? Is there a better way to be running these aside from `ant 
test` to build sanely?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/fb4fdabe-5b33-4004-8d4b-1e8ba13a07cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

I'm ok with restricting them to @JsFunction java8 lambdas. That's
likely to be the common path for web oriented code for event handling.


On Mon, Apr 18, 2016 at 10:47 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> That is why I am saying that it will be easy to do for JsFunctions but due
> to Java semantics (regular) lambdas are just not plain functions and thus I
> don't think there is much to gain there.
>
> I don't think there is much to gain on the regular lambdas. There are 2
> different ways we can handle them and reduce a bit of the generated code but
> I don't think there is a lot of potential ways.
> 1) do not generate anonymous inner classes, rather have the make lambda
> factory take all the required parameters, i.e. castmap.
> 2) create an anonymous innerclass based on the class/interface that is being
> extended/implemented when a lambda for that is seen. In that way if an
> interface is used with many lambdas there is only one supporting class
> instead of many.
>
>
> On Mon, Apr 18, 2016 at 10:22 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> I understand, but the trampolines cause bloat, and if you're
>> suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
>> far as code-gen is concerned, then you would not be able to make the
>> following code work:
>>
>> foo(Callable x) { bar(x); }
>> foo(Runnable x) { bar(x); }
>>
>> bar(Object x) { if (x instanceof Callable) { print("it's a callable");
>> } else if (x instanceof Runnable) { print("It's a runnable"); } }
>>
>> You need a castMap for that.
>>
>>
>> On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > The point is that for JsFunctions you DON'T actually need to do the
>> > makeLambda(). JsFunction was designed to be able to pass JS functions to
>> > JAVA so there is a code path for that and we can exploit it for
>> > JsFunction
>> > lambdas.
>> >
>> > So x -> 42  + capture will be represented in the JAva AST as
>> > class X {
>> >   {
>> >  .  new X$0(capture);
>> >   }
>> >   // Synthetic lambda method
>> >   int lambda_f(capture, x) {
>> >  return 42 + capture;
>> >   }
>> >
>> > // Lambda function implmenetation. Nothing needs to be emitted for this
>> > in
>> > JS
>> > class X$0 implements JsFunctionInterface {
>> >   capture;
>> >   X$0(capture) {
>> >this.capture = capture;
>> >   }
>> >
>> >   int m(x) {
>> >  X.lambda_f(this.capture, x);
>> >   }
>> > }
>> >
>> >
>> > In the JS ast we do
>> >
>> >   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
>> >
>> > So we don't need makeLambda or anything else; we can just treat
>> > JsFunciton
>> > implementation as if they were functions passed in from JavaScript where
>> > object methods will go through the regular trampoline into the "JSO"
>> > implementation.
>> >
>> >
>> >
>> >
>> > On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
>> >  wrote:
>> >>
>> >> That seems similar to my proposal, only you're doing it in GenJsAST.
>> >> You'll still need to the makeLambda() trick to allow it to work as a
>> >> regular obejct as well, with hashCode()/equals()/getClass()
>> >> properties, as well as castMap installed. But if you use static method
>> >> delegation, the size won't be as ideal if the static method doesn't
>> >> inline.
>> >>
>> >> You want something like x -> 42 + capture to compile to
>> >> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
>> >> not function(x) { return Class.foo(capture, x); } do you not?
>> >>
>> >>
>> >> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
>> >> Contributors  wrote:
>> >> > The scheme I had in mind does not modify much the Java AST
>> >> > representation
>> >> > but is more in the lowering to the JsAST, basically it boils down the
>> >> > the
>> >> > following:.
>> >> > 1. You create the lambda body as a static method of the class where
>> >> > it
>> >> > appears. This static method has all captures as parameters (thiis is
>> >> > very
>> >> > similar as we are doing today).
>> >> > 2. Synthesize an anonymous inner class that implement the JsFunciton
>> >> > (also
>> >> > same as we are doing now). The compiler in the java phase sees this
>> >> > as
>> >> > an
>> >> > innerclass.
>> >> > 3. Emit the following code for new JsFuncitonimplementation(capture1,
>> >> > capture2) as function(par1, par2, parn) ->
>> >> > {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2,
>> >> > parn) }.
>> >> > 4. Do not emit any code for the anonymous inner class.
>> >> >
>> >> > This function will behave as if it was a native function passed from
>> >> > JS,
>> >> > and
>> >> > object methods will work in the same way. Of course the devil is in
>> >> > the
>> >> > details.
>> >> >
>> >> >
>> >> > On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
>> >> >  wrote:
>> >> >>
>> >> >> Seems to me this'll be tricky to pull off. The GWT compiler has no
>> >> >> notion of capt

Re: [gwt-contrib] Lambda overhead

['Roberto Lublinerman' via GWT Contributors]

That is why I am saying that it will be easy to do for JsFunctions but due
to Java semantics (regular) lambdas are just not plain functions and thus I
don't think there is much to gain there.

I don't think there is much to gain on the regular lambdas. There are 2
different ways we can handle them and reduce a bit of the generated code
but I don't think there is a lot of potential ways.
1) do not generate anonymous inner classes, rather have the make lambda
factory take all the required parameters, i.e. castmap.
2) create an anonymous innerclass based on the class/interface that is
being extended/implemented when a lambda for that is seen. In that way if
an interface is used with many lambdas there is only one supporting class
instead of many.


On Mon, Apr 18, 2016 at 10:22 AM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> I understand, but the trampolines cause bloat, and if you're
> suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
> far as code-gen is concerned, then you would not be able to make the
> following code work:
>
> foo(Callable x) { bar(x); }
> foo(Runnable x) { bar(x); }
>
> bar(Object x) { if (x instanceof Callable) { print("it's a callable");
> } else if (x instanceof Runnable) { print("It's a runnable"); } }
>
> You need a castMap for that.
>
>
> On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
> Contributors  wrote:
> > The point is that for JsFunctions you DON'T actually need to do the
> > makeLambda(). JsFunction was designed to be able to pass JS functions to
> > JAVA so there is a code path for that and we can exploit it for
> JsFunction
> > lambdas.
> >
> > So x -> 42  + capture will be represented in the JAva AST as
> > class X {
> >   {
> >  .  new X$0(capture);
> >   }
> >   // Synthetic lambda method
> >   int lambda_f(capture, x) {
> >  return 42 + capture;
> >   }
> >
> > // Lambda function implmenetation. Nothing needs to be emitted for this
> in
> > JS
> > class X$0 implements JsFunctionInterface {
> >   capture;
> >   X$0(capture) {
> >this.capture = capture;
> >   }
> >
> >   int m(x) {
> >  X.lambda_f(this.capture, x);
> >   }
> > }
> >
> >
> > In the JS ast we do
> >
> >   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
> >
> > So we don't need makeLambda or anything else; we can just treat
> JsFunciton
> > implementation as if they were functions passed in from JavaScript where
> > object methods will go through the regular trampoline into the "JSO"
> > implementation.
> >
> >
> >
> >
> > On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
> >  wrote:
> >>
> >> That seems similar to my proposal, only you're doing it in GenJsAST.
> >> You'll still need to the makeLambda() trick to allow it to work as a
> >> regular obejct as well, with hashCode()/equals()/getClass()
> >> properties, as well as castMap installed. But if you use static method
> >> delegation, the size won't be as ideal if the static method doesn't
> >> inline.
> >>
> >> You want something like x -> 42 + capture to compile to
> >> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
> >> not function(x) { return Class.foo(capture, x); } do you not?
> >>
> >>
> >> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
> >> Contributors  wrote:
> >> > The scheme I had in mind does not modify much the Java AST
> >> > representation
> >> > but is more in the lowering to the JsAST, basically it boils down the
> >> > the
> >> > following:.
> >> > 1. You create the lambda body as a static method of the class where it
> >> > appears. This static method has all captures as parameters (thiis is
> >> > very
> >> > similar as we are doing today).
> >> > 2. Synthesize an anonymous inner class that implement the JsFunciton
> >> > (also
> >> > same as we are doing now). The compiler in the java phase sees this as
> >> > an
> >> > innerclass.
> >> > 3. Emit the following code for new JsFuncitonimplementation(capture1,
> >> > capture2) as function(par1, par2, parn) ->
> >> > {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2,
> >> > parn) }.
> >> > 4. Do not emit any code for the anonymous inner class.
> >> >
> >> > This function will behave as if it was a native function passed from
> JS,
> >> > and
> >> > object methods will work in the same way. Of course the devil is in
> the
> >> > details.
> >> >
> >> >
> >> > On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
> >> >  wrote:
> >> >>
> >> >> Seems to me this'll be tricky to pull off. The GWT compiler has no
> >> >> notion of captured scope. If you want to create a class type that
> >> >> represents a lambda, but which doesn't actually get output as a
> class,
> >> >> you'd have to change many many parts of the compiler.
> >> >>
> >> >> I think perhaps the best thing you could do would be a kind of
> >> >> 'peephole' optimization pass. After all Java optimization passes h

Re: [gwt-contrib] Lambda overhead

['Roberto Lublinerman' via GWT Contributors]

The point is that for JsFunctions you DON'T actually need to do the
makeLambda(). JsFunction was designed to be able to pass JS functions to
JAVA so there is a code path for that and we can exploit it for JsFunction
lambdas.

So x -> 42  + capture will be represented in the JAva AST as
class X {
  {
 .  new X$0(capture);
  }
  // Synthetic lambda method
  int lambda_f(capture, x) {
 return 42 + capture;
  }

// Lambda function implmenetation. Nothing needs to be emitted for this in
JS
class X$0 implements JsFunctionInterface {
  capture;
  X$0(capture) {
   this.capture = capture;
  }

  int m(x) {
 X.lambda_f(this.capture, x);
  }
}


In the JS ast we do

  new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }

So we don't need makeLambda or anything else; we can just treat JsFunciton
implementation as if they were functions passed in from JavaScript where
object methods will go through the regular trampoline into the "JSO"
implementation.




On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> That seems similar to my proposal, only you're doing it in GenJsAST.
> You'll still need to the makeLambda() trick to allow it to work as a
> regular obejct as well, with hashCode()/equals()/getClass()
> properties, as well as castMap installed. But if you use static method
> delegation, the size won't be as ideal if the static method doesn't
> inline.
>
> You want something like x -> 42 + capture to compile to
> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
> not function(x) { return Class.foo(capture, x); } do you not?
>
>
> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
> Contributors  wrote:
> > The scheme I had in mind does not modify much the Java AST representation
> > but is more in the lowering to the JsAST, basically it boils down the the
> > following:.
> > 1. You create the lambda body as a static method of the class where it
> > appears. This static method has all captures as parameters (thiis is very
> > similar as we are doing today).
> > 2. Synthesize an anonymous inner class that implement the JsFunciton
> (also
> > same as we are doing now). The compiler in the java phase sees this as an
> > innerclass.
> > 3. Emit the following code for new JsFuncitonimplementation(capture1,
> > capture2) as function(par1, par2, parn) ->
> > {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2,
> parn) }.
> > 4. Do not emit any code for the anonymous inner class.
> >
> > This function will behave as if it was a native function passed from JS,
> and
> > object methods will work in the same way. Of course the devil is in the
> > details.
> >
> >
> > On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
> >  wrote:
> >>
> >> Seems to me this'll be tricky to pull off. The GWT compiler has no
> >> notion of captured scope. If you want to create a class type that
> >> represents a lambda, but which doesn't actually get output as a class,
> >> you'd have to change many many parts of the compiler.
> >>
> >> I think perhaps the best thing you could do would be a kind of
> >> 'peephole' optimization pass. After all Java optimization passes have
> >> run, and after JS has been generated, go through using pattern
> >> matching to find "new generatedlambda(captured variables)" and replace
> >> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
> >> body of single abstract method })". Then hope the JS dead code pruning
> >> removes the unused inner class.
> >>
> >> I think if you try to model this in the Java AST it would impact too
> much
> >> stuff.
> >>
> >>
> >> On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
> >> Contributors  wrote:
> >> > We accept patches :)
> >> >
> >> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley 
> >> > wrote:
> >> >>
> >> >> Given that it will be realistically a couple of years before most
> large
> >> >> projects could migrate to J2CL, it would be really nice to have a
> more
> >> >> optimal code generation for lambda's, especially for JsFunction. When
> >> >> 2.8
> >> >> gets released, I think people will really start taking advantage of
> >> >> existing
> >> >> JS libraries that really heavily use functions.
> >> >>
> >> >>
> >> >> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman
> >> >> wrote:
> >> >>>
> >> >>> It should not be hard to make JsFunction lambdas more terse, but
> there
> >> >>> are no plans for GWT 2.x.
> >> >>>
> >> >>>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> Groups
> >> >> "GWT Contributors" group.
> >> >> To unsubscribe from this group and stop receiving emails from it,
> send
> >> >> an
> >> >> email to
> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> >> >> To view this discussion on the web visit
> >> >>
> >> >>
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

I understand, but the trampolines cause bloat, and if you're
suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
far as code-gen is concerned, then you would not be able to make the
following code work:

foo(Callable x) { bar(x); }
foo(Runnable x) { bar(x); }

bar(Object x) { if (x instanceof Callable) { print("it's a callable");
} else if (x instanceof Runnable) { print("It's a runnable"); } }

You need a castMap for that.


On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> The point is that for JsFunctions you DON'T actually need to do the
> makeLambda(). JsFunction was designed to be able to pass JS functions to
> JAVA so there is a code path for that and we can exploit it for JsFunction
> lambdas.
>
> So x -> 42  + capture will be represented in the JAva AST as
> class X {
>   {
>  .  new X$0(capture);
>   }
>   // Synthetic lambda method
>   int lambda_f(capture, x) {
>  return 42 + capture;
>   }
>
> // Lambda function implmenetation. Nothing needs to be emitted for this in
> JS
> class X$0 implements JsFunctionInterface {
>   capture;
>   X$0(capture) {
>this.capture = capture;
>   }
>
>   int m(x) {
>  X.lambda_f(this.capture, x);
>   }
> }
>
>
> In the JS ast we do
>
>   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
>
> So we don't need makeLambda or anything else; we can just treat JsFunciton
> implementation as if they were functions passed in from JavaScript where
> object methods will go through the regular trampoline into the "JSO"
> implementation.
>
>
>
>
> On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> That seems similar to my proposal, only you're doing it in GenJsAST.
>> You'll still need to the makeLambda() trick to allow it to work as a
>> regular obejct as well, with hashCode()/equals()/getClass()
>> properties, as well as castMap installed. But if you use static method
>> delegation, the size won't be as ideal if the static method doesn't
>> inline.
>>
>> You want something like x -> 42 + capture to compile to
>> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
>> not function(x) { return Class.foo(capture, x); } do you not?
>>
>>
>> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > The scheme I had in mind does not modify much the Java AST
>> > representation
>> > but is more in the lowering to the JsAST, basically it boils down the
>> > the
>> > following:.
>> > 1. You create the lambda body as a static method of the class where it
>> > appears. This static method has all captures as parameters (thiis is
>> > very
>> > similar as we are doing today).
>> > 2. Synthesize an anonymous inner class that implement the JsFunciton
>> > (also
>> > same as we are doing now). The compiler in the java phase sees this as
>> > an
>> > innerclass.
>> > 3. Emit the following code for new JsFuncitonimplementation(capture1,
>> > capture2) as function(par1, par2, parn) ->
>> > {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2,
>> > parn) }.
>> > 4. Do not emit any code for the anonymous inner class.
>> >
>> > This function will behave as if it was a native function passed from JS,
>> > and
>> > object methods will work in the same way. Of course the devil is in the
>> > details.
>> >
>> >
>> > On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
>> >  wrote:
>> >>
>> >> Seems to me this'll be tricky to pull off. The GWT compiler has no
>> >> notion of captured scope. If you want to create a class type that
>> >> represents a lambda, but which doesn't actually get output as a class,
>> >> you'd have to change many many parts of the compiler.
>> >>
>> >> I think perhaps the best thing you could do would be a kind of
>> >> 'peephole' optimization pass. After all Java optimization passes have
>> >> run, and after JS has been generated, go through using pattern
>> >> matching to find "new generatedlambda(captured variables)" and replace
>> >> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
>> >> body of single abstract method })". Then hope the JS dead code pruning
>> >> removes the unused inner class.
>> >>
>> >> I think if you try to model this in the Java AST it would impact too
>> >> much
>> >> stuff.
>> >>
>> >>
>> >> On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
>> >> Contributors  wrote:
>> >> > We accept patches :)
>> >> >
>> >> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley 
>> >> > wrote:
>> >> >>
>> >> >> Given that it will be realistically a couple of years before most
>> >> >> large
>> >> >> projects could migrate to J2CL, it would be really nice to have a
>> >> >> more
>> >> >> optimal code generation for lambda's, especially for JsFunction.
>> >> >> When
>> >> >> 2.8
>> >> >> gets released, I think people will really start taking advantage of
>> >> >> existing
>> >> >> JS libraries that really heavily use functions.
>> >> >>
>

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

That seems similar to my proposal, only you're doing it in GenJsAST.
You'll still need to the makeLambda() trick to allow it to work as a
regular obejct as well, with hashCode()/equals()/getClass()
properties, as well as castMap installed. But if you use static method
delegation, the size won't be as ideal if the static method doesn't
inline.

You want something like x -> 42 + capture to compile to
makeLambda(function(x) { return 42 + capture }, castMap, classLit),
not function(x) { return Class.foo(capture, x); } do you not?


On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> The scheme I had in mind does not modify much the Java AST representation
> but is more in the lowering to the JsAST, basically it boils down the the
> following:.
> 1. You create the lambda body as a static method of the class where it
> appears. This static method has all captures as parameters (thiis is very
> similar as we are doing today).
> 2. Synthesize an anonymous inner class that implement the JsFunciton (also
> same as we are doing now). The compiler in the java phase sees this as an
> innerclass.
> 3. Emit the following code for new JsFuncitonimplementation(capture1,
> capture2) as function(par1, par2, parn) ->
> {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2, parn) }.
> 4. Do not emit any code for the anonymous inner class.
>
> This function will behave as if it was a native function passed from JS, and
> object methods will work in the same way. Of course the devil is in the
> details.
>
>
> On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> Seems to me this'll be tricky to pull off. The GWT compiler has no
>> notion of captured scope. If you want to create a class type that
>> represents a lambda, but which doesn't actually get output as a class,
>> you'd have to change many many parts of the compiler.
>>
>> I think perhaps the best thing you could do would be a kind of
>> 'peephole' optimization pass. After all Java optimization passes have
>> run, and after JS has been generated, go through using pattern
>> matching to find "new generatedlambda(captured variables)" and replace
>> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
>> body of single abstract method })". Then hope the JS dead code pruning
>> removes the unused inner class.
>>
>> I think if you try to model this in the Java AST it would impact too much
>> stuff.
>>
>>
>> On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > We accept patches :)
>> >
>> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley 
>> > wrote:
>> >>
>> >> Given that it will be realistically a couple of years before most large
>> >> projects could migrate to J2CL, it would be really nice to have a more
>> >> optimal code generation for lambda's, especially for JsFunction. When
>> >> 2.8
>> >> gets released, I think people will really start taking advantage of
>> >> existing
>> >> JS libraries that really heavily use functions.
>> >>
>> >>
>> >> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman
>> >> wrote:
>> >>>
>> >>> It should not be hard to make JsFunction lambdas more terse, but there
>> >>> are no plans for GWT 2.x.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "GWT Contributors" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "GWT Contributors" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7g%3DkH9YQjA_P02ibv-Fg4u-gRW6s4Ojm6S2KgTK0KDOYmQ%40mail.gmail.com.
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7csJ3vykGQ1rt%2BSTZtYL0cwjMH8zzY0zgiHszfETPg4Dw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" 

Re: [gwt-contrib] Lambda overhead

['Roberto Lublinerman' via GWT Contributors]

The scheme I had in mind does not modify much the Java AST representation
but is more in the lowering to the JsAST, basically it boils down the the
following:.
1. You create the lambda body as a static method of the class where it
appears. This static method has all captures as parameters (thiis is very
similar as we are doing today).
2. Synthesize an anonymous inner class that implement the JsFunciton (also
same as we are doing now). The compiler in the java phase sees this as an
innerclass.
3. Emit the following code for new JsFuncitonimplementation(capture1,
capture2) as function(par1, par2, parn) ->
{Class.lambdaFunctionImplementation(capture1, capture2, par1, par2, parn)
}.
4. Do not emit any code for the anonymous inner class.

This function will behave as if it was a native function passed from JS,
and object methods will work in the same way. Of course the devil is in the
details.


On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Seems to me this'll be tricky to pull off. The GWT compiler has no
> notion of captured scope. If you want to create a class type that
> represents a lambda, but which doesn't actually get output as a class,
> you'd have to change many many parts of the compiler.
>
> I think perhaps the best thing you could do would be a kind of
> 'peephole' optimization pass. After all Java optimization passes have
> run, and after JS has been generated, go through using pattern
> matching to find "new generatedlambda(captured variables)" and replace
> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
> body of single abstract method })". Then hope the JS dead code pruning
> removes the unused inner class.
>
> I think if you try to model this in the Java AST it would impact too much
> stuff.
>
>
> On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
> Contributors  wrote:
> > We accept patches :)
> >
> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley 
> wrote:
> >>
> >> Given that it will be realistically a couple of years before most large
> >> projects could migrate to J2CL, it would be really nice to have a more
> >> optimal code generation for lambda's, especially for JsFunction. When
> 2.8
> >> gets released, I think people will really start taking advantage of
> existing
> >> JS libraries that really heavily use functions.
> >>
> >>
> >> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman
> wrote:
> >>>
> >>> It should not be hard to make JsFunction lambdas more terse, but there
> >>> are no plans for GWT 2.x.
> >>>
> >>>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "GWT Contributors" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com
> .
> >>
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "GWT Contributors" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7g%3DkH9YQjA_P02ibv-Fg4u-gRW6s4Ojm6S2KgTK0KDOYmQ%40mail.gmail.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7csJ3vykGQ1rt%2BSTZtYL0cwjMH8zzY0zgiHszfETPg4Dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gngwS13pEuSHWSMZAtcScTPwuH8tKRNGT7fQMBxa_S2jQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

Seems to me this'll be tricky to pull off. The GWT compiler has no
notion of captured scope. If you want to create a class type that
represents a lambda, but which doesn't actually get output as a class,
you'd have to change many many parts of the compiler.

I think perhaps the best thing you could do would be a kind of
'peephole' optimization pass. After all Java optimization passes have
run, and after JS has been generated, go through using pattern
matching to find "new generatedlambda(captured variables)" and replace
it with "makeLambda(classtype, castMap, classLiteral, function(...) {
body of single abstract method })". Then hope the JS dead code pruning
removes the unused inner class.

I think if you try to model this in the Java AST it would impact too much stuff.


On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> We accept patches :)
>
> On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley  wrote:
>>
>> Given that it will be realistically a couple of years before most large
>> projects could migrate to J2CL, it would be really nice to have a more
>> optimal code generation for lambda's, especially for JsFunction. When 2.8
>> gets released, I think people will really start taking advantage of existing
>> JS libraries that really heavily use functions.
>>
>>
>> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman wrote:
>>>
>>> It should not be hard to make JsFunction lambdas more terse, but there
>>> are no plans for GWT 2.x.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7g%3DkH9YQjA_P02ibv-Fg4u-gRW6s4Ojm6S2KgTK0KDOYmQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7csJ3vykGQ1rt%2BSTZtYL0cwjMH8zzY0zgiHszfETPg4Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Lambda overhead

['Roberto Lublinerman' via GWT Contributors]

We accept patches :)

On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley  wrote:

> Given that it will be realistically a couple of years before most large
> projects could migrate to J2CL, it would be really nice to have a more
> optimal code generation for lambda's, especially for JsFunction. When 2.8
> gets released, I think people will really start taking advantage of
> existing JS libraries that really heavily use functions.
>
>
> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman wrote:
>>
>> It should not be hard to make JsFunction lambdas more terse, but there
>> are no plans for GWT 2.x.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7g%3DkH9YQjA_P02ibv-Fg4u-gRW6s4Ojm6S2KgTK0KDOYmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] JsInterop with separate GWT module compilation

[Ahmad Bawaneh]

Hi All,

is there any sample for using JsInterop to make communication between GWT 
module compiled each on its own?
i think this will be a good idea to start implementing client side plugins 
and modularity.
 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/8774ce7f-e7b6-4a9c-bafb-93086f40e728%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.