[gwt-contrib] dev tests failing locally?

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,

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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 {

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

[gwt-contrib] JsInterop with separate GWT module compilation

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