[gwt-contrib] Java 8 Support

Hey guys, I'd like to help out in any way I can, with bringing Java 8 support to GWT. Last I heard, the language features like lambdas were done, and only the APIs were missing. I can help port some of the APIs if that's needed. Thanks. -- You received this message because you are subscribed

[gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

Hi all, the smoke testing for the release showed up a couple of problems, some of them need to be fixed before we put RC1 out others can wait until the final release. - Dev mode test do not work: issue 8967 - Smoke te

Re: [gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

On Tue, Oct 28, 2014 at 4:05 PM, 'Daniel Kurka' via GWT Contributors < google-web-toolkit-contributors@googlegroups.com> wrote: > Hi all, > > the smoke testing for the release showed up a couple of problems, some of > them need to be fixed before we put RC1 out others can wait until the final > re

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

What is the difference in using the following? *@JsType(prototype="Window"**)* and *@JsType * It does not become very clear from the documentation. Here is the interface I implemented: @JsType(prototype="Window") public interface MyWindow { public static abstract class Statics { public s

Re: [gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

Fixed the JSON example, it was not a Yahoo issue since the yahoo response is in a .json file in the project. The problem is that 2.7.0 disallows entry classes not implementing the interface EntryPoint. https://gwt-review.googlesource.com/#/c/9994/ On Tue, Oct 28, 2014 at 4:07 PM, Manuel Carrasco

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

GWT.create() doesn't work to create Js interfaces. It's part of the GWT deferred binding system and can only be bound to concrete Java subtypes. (GWT.create uses the 'new' operator) JsInterop is going to move towards Java8 syntax for the use case you describe, e.g @JsType interface Window { st

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

Okay great. But what is the difference between the following? *@JsType(prototype="Window"**)* and *@JsType * Also could you please explain when to use isNative = true? Am Dienstag, 28. Oktober 2014 17:06:47 UTC+1 schrieb Ray Cromwell: > > GWT.create() doesn't work to create Js interfaces. It'

[gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev

Hi all, right now GWT builds with RC1 are failing in Eclipse with GPE since the gwt-codeserver.jar is not on the build path. The next GPE release (with changes that fix this) is still a long way out. In order to not be blocking on this I propose we fold gwt-codeserver.jar into gwt-dev.jar. This w

[gwt-contrib] Re: Blocking RC1: Fold gwt-codeserver into gwt-dev

I like this idea of moving codeserver into core. I think this would make it easier. -Brandon -- 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-to

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

@JsType(prototype="Window") means that "x instanceof Window" will return false if the underlying object isn't a Window. That is, the GWT compiler generates a JS instanceof operator with the specified prototype. Otherwise, @JsType interfaces are treated like JavaScriptObject overlay types as far as

[gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev

Fine for me. Do you intend to move the sources or just merge the JARs during dist-dev/dist? -- 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-toolk

Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev

I think moving sources right now is too risky and too much work we should just merge the jars in dist. On Tue, Oct 28, 2014 at 8:02 PM, Thomas Broyer wrote: > Fine for me. > > Do you intend to move the sources or just merge the JARs during > dist-dev/dist? > > -- > You received this message beca

Re: [gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

On Tue, Oct 28, 2014 at 8:05 AM, 'Daniel Kurka' via GWT Contributors < google-web-toolkit-contributors@googlegroups.com> wrote: > Hi all, > > the smoke testing for the release showed up a couple of problems, some of > them need to be fixed before we put RC1 out others can wait until the final > re

Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev

Yes, merging the jars should be fine as a short-term fix. Codeserver should be built as a separate library to enforce that there are no circular dependencies. (We already have one for DevMode -superDevMode but that should be fixed by splitting out DevMode; it doesn't belong in the same library as

Re: [gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

I suspect that the designer needs to be recompiled; do you want to provide the old api so that we don't need to rebuild the designer? On Tue, Oct 28, 2014 at 12:50 PM, Goktug Gokdogan wrote: > > > On Tue, Oct 28, 2014 at 8:05 AM, 'Daniel Kurka' via GWT Contributors < > google-web-toolkit-contrib

Re: [gwt-contrib] GWT 2.7.0-RC1 Smoke testing update

If it is feasible yes. I'm not sure if we can do a designer release at this point. We can put back the removed method and mark it deprecated. On Tue, Oct 28, 2014 at 1:58 PM, Roberto Lublinerman wrote: > I suspect that the designer needs to be recompiled; do you want to provide > the old api so

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

Today finally I had some free time to think about the rest of the issues (extending, constructors, static functions etc). I'm going to make another attempt to make those pieces work better and less boilerplatey. Will update the thread if I find something that is worth sharing. On Tue, Oct 28, 2014