[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 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/630b9563-62cd-4f82-8848-d4e96ec19318%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[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 https://code.google.com/p/google-web-toolkit/issues/detail?id=8967 - Smoke tests fail with GPE since gwt-codeserver.jar is missing on the classpath. We need to either modify GPE or put codeserver classes into gwt-dev - GWT designer crashes: see screenshot https://drive.google.com/file/d/0B-K8EZ6jAAQrVzdweDhiTE5iQlU/view - JSON Sample does not work since the yahoo search returns a 404 Can somebody please take a look at updating the JSON Sample to use a different service for the actual search? -Daniel -- 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/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 release. - Dev mode test do not work: issue 8967 https://code.google.com/p/google-web-toolkit/issues/detail?id=8967 - Smoke tests fail with GPE since gwt-codeserver.jar is missing on the classpath. We need to either modify GPE or put codeserver classes into gwt-dev - GWT designer crashes: see screenshot https://drive.google.com/file/d/0B-K8EZ6jAAQrVzdweDhiTE5iQlU/view - JSON Sample does not work since the yahoo search returns a 404 Can somebody please take a look at updating the JSON Sample to use a different service for the actual search? Ok I'll do -Daniel -- 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/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAM28XAvw6vGei_i50si7P%3DD6H%3DGVii0RQXHt2hbkmk0dixjO%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 static native MyWindow create() /*-{
var w = $wnd;
return w;
}-*/;
}
void alert(String msg);
}
When I want to use the interface I have to do: *MyWindow w =
MyWindow.Statics.create();*
I also would expect that the following should work too: *MyWindow w =
GWT.create(MyWindow.class);*
The compiler throws an error in the later case:
[ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
Unification traversed 735 fields and methods and 538 types. 7 are
considered part of the current module and 7 had all of their fields and
methods traversed.
[ERROR] Compiler returned false
Two questions:
*1. When do I use or do I not use the prototype and isNative attribute of
@JsType?*
*2. Do I use the correct way to instantiate a JSInterop Interface?*
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
javascript: wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String event,
com.workingflows.js.jscore.client.api.Function?,? fn);
void attr(String attr, Object value);
}
Now suppose that there is an element called SwitchElement, the item is a
JQueryElement but has a particual implementation of a method, for
example:
public class SwitchElement extends JavaScriptObject {
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
The problem is, if the JQueryElement interface is implemented, all
methods
must be implemented. In fact, the implementation of JQueryElement is
performed by the compiler, and I have no access to that implentación.
1) The solution can be: define an Java8 interface with methods
implemented
by default?
2) It is possible to access a Prototype implementation of JQueryElement,
by
example:
public class SwitchElement extends JQueryElement.Prototype{
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
But for this, it is necessary to use APT or the JsType generation
process,
is performed by APT.
I'm right, or very far from reality.
:)
El sábado, 4 de octubre de 2014 15:24:19 UTC-3, Ray Cromwell escribió:
Yes, but it will require Java8, which allows interfaces to contain
static methods. Here's how you'll do it soon when the Java8 stuff
lands:
@JsType
public interface ImageUtils {
public static Texture
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 Moñino man...@apache.org wrote: 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 release. - Dev mode test do not work: issue 8967 https://code.google.com/p/google-web-toolkit/issues/detail?id=8967 - Smoke tests fail with GPE since gwt-codeserver.jar is missing on the classpath. We need to either modify GPE or put codeserver classes into gwt-dev - GWT designer crashes: see screenshot https://drive.google.com/file/d/0B-K8EZ6jAAQrVzdweDhiTE5iQlU/view - JSON Sample does not work since the yahoo search returns a 404 Can somebody please take a look at updating the JSON Sample to use a different service for the actual search? Ok I'll do -Daniel -- 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/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAM28XAtK0MoG8VW0Pi20VJV2n5UrFJGEtKW5X_DUH%3D7%2BBtL22A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 {
static Window get() { return js(window); }
}
On Tue, Oct 28, 2014 at 8:33 AM, confile
michael.gorsk...@googlemail.com wrote:
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 static native MyWindow create() /*-{
var w = $wnd;
return w;
}-*/;
}
void alert(String msg);
}
When I want to use the interface I have to do: MyWindow w =
MyWindow.Statics.create();
I also would expect that the following should work too: MyWindow w =
GWT.create(MyWindow.class);
The compiler throws an error in the later case:
[ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
Unification traversed 735 fields and methods and 538 types. 7 are
considered part of the current module and 7 had all of their fields and
methods traversed.
[ERROR] Compiler returned false
Two questions:
1. When do I use or do I not use the prototype and isNative attribute of
@JsType?
2. Do I use the correct way to instantiate a JSInterop Interface?
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String event,
com.workingflows.js.jscore.client.api.Function?,? fn);
void attr(String attr, Object value);
}
Now suppose that there is an element called SwitchElement, the item is a
JQueryElement but has a particual implementation of a method, for
example:
public class SwitchElement extends JavaScriptObject {
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
The problem is, if the JQueryElement interface is implemented, all
methods
must be implemented. In fact, the implementation of JQueryElement is
performed by the compiler, and I have no access to that implentación.
1) The solution can be: define an Java8 interface with methods
implemented
by default?
2) It is possible to access a Prototype implementation of JQueryElement,
by
example:
public class SwitchElement extends JQueryElement.Prototype{
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
But for this, it is necessary to use APT or the JsType generation
process,
is performed by APT.
I'm right, or very far from reality.
:)
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'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 {
static Window get() { return js(window); }
}
On Tue, Oct 28, 2014 at 8:33 AM, confile
michael@googlemail.com javascript: wrote:
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 static native MyWindow create() /*-{
var w = $wnd;
return w;
}-*/;
}
void alert(String msg);
}
When I want to use the interface I have to do: MyWindow w =
MyWindow.Statics.create();
I also would expect that the following should work too: MyWindow w =
GWT.create(MyWindow.class);
The compiler throws an error in the later case:
[ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
Unification traversed 735 fields and methods and 538 types. 7
are
considered part of the current module and 7 had all of their fields and
methods traversed.
[ERROR] Compiler returned false
Two questions:
1. When do I use or do I not use the prototype and isNative attribute of
@JsType?
2. Do I use the correct way to instantiate a JSInterop Interface?
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String event,
com.workingflows.js.jscore.client.api.Function?,? fn);
void attr(String attr, Object value);
}
Now suppose that there is an element called SwitchElement, the item
is a
JQueryElement but has a particual implementation of a method, for
example:
public class SwitchElement extends JavaScriptObject {
protected SwitchElement() {
}
public final native boolean getState()/*-{
return this.bootstrapSwitch(state);
}-*/;
public final native void setState(boolean state)/*-{
this.bootstrapSwitch(state, state);
}-*/;
}
The problem is, if the JQueryElement interface is implemented, all
methods
must be implemented. In fact, the implementation of JQueryElement is
performed by the compiler, and I have no access to that implentación.
1) The solution can be: define an Java8 interface with methods
[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 way people do not have to deal with the extra complexity of adding yet another entry into the classpath and all the old tools just work. If I do not hear any objections as of today, I go ahead and change the OS build (I could need some help here). So please speak up. -Daniel -- 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/CALLujiqxC1b4UCn-N-FNRSLkaUzSUJF%3DEgJKXWE3A30Mh9OFkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[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-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0c632a48-300e-4898-b1b7-664924cb67bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 castability/instanceof is concerned.
isNative is just documentation for now, but says that the underlying
prototype is a browser built-in as opposed to a hand written user supplied
JS prototype. Native prototypes have restrictions that pure-JS ones don't.
@JsType(prototype=...) will also trigger an annotation processor in the
future that generates a stub _Prototype for extending, e.g.
@JsType(prototype=HTMLDivElement)
interface HTMLDivElement extends HTMLElement { ... }
will generate a
@PrototypeOfJsType(HTMLDivElement.class)
class HtmlDivElement_Prototype extends HTMLElement_Prototype { ... }
This makes it possible to subclass JS objects, e.g.
class MyDivElement extends HTMLDivElement_Prototype { ... }
On Tue Oct 28 2014 at 9:17:55 AM confile michael.gorsk...@googlemail.com
wrote:
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'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 {
static Window get() { return js(window); }
}
On Tue, Oct 28, 2014 at 8:33 AM, confile
michael@googlemail.com wrote:
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 static native MyWindow create() /*-{
var w = $wnd;
return w;
}-*/;
}
void alert(String msg);
}
When I want to use the interface I have to do: MyWindow w =
MyWindow.Statics.create();
I also would expect that the following should work too: MyWindow w =
GWT.create(MyWindow.class);
The compiler throws an error in the later case:
[ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
Unification traversed 735 fields and methods and 538 types. 7
are
considered part of the current module and 7 had all of their fields and
methods traversed.
[ERROR] Compiler returned false
Two questions:
1. When do I use or do I not use the prototype and isNative attribute
of
@JsType?
2. Do I use the correct way to instantiate a JSInterop Interface?
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.
Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org
On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi csri...@gmail.com
wrote:
+Ray Cromwell:
Suppose the following definition:
@JsType(prototype = jQuery)
public interface JQueryElement {
JQueryElement append(JQueryElement element);
@JsProperty
JQueryElement html();
void data(String key, String value);
Object val();
void on(String
[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-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 t.bro...@gmail.com wrote: 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-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 release. - Dev mode test do not work: issue 8967 https://code.google.com/p/google-web-toolkit/issues/detail?id=8967 - Smoke tests fail with GPE since gwt-codeserver.jar is missing on the classpath. We need to either modify GPE or put codeserver classes into gwt-dev - GWT designer crashes: see screenshot https://drive.google.com/file/d/0B-K8EZ6jAAQrVzdweDhiTE5iQlU/view @rluble: Can you take look at this one. It is probably an API change in ModuleDefLoader and it might be an easy fix. - JSON Sample does not work since the yahoo search returns a 404 Can somebody please take a look at updating the JSON Sample to use a different service for the actual search? -Daniel -- 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/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAN%3DyUA2SgyvYjFC-ZZTwyASa9S%2Bnhqir9Uap5xiTw%2BopQGiwyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 the compiler.) Long term, we will also want to split gwt-user into multiple jars. It seems like we should either give plugins a way to set up the classpath properly without hard-coding exactly which jars to use, or else plan on building the traditional all-in-one jars when creating the distribution. On Tue Oct 28 2014 at 12:03:25 PM 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: 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 t.bro...@gmail.com wrote: 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-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CA%2B%2BRBT90OfBtkUfSpwpb4L6jQkbwNAyH-52Yrgeqvpc9wYMk1w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 rlu...@google.com wrote: 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 gok...@google.com wrote: 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 release. - Dev mode test do not work: issue 8967 https://code.google.com/p/google-web-toolkit/issues/detail?id=8967 - Smoke tests fail with GPE since gwt-codeserver.jar is missing on the classpath. We need to either modify GPE or put codeserver classes into gwt-dev - GWT designer crashes: see screenshot https://drive.google.com/file/d/0B-K8EZ6jAAQrVzdweDhiTE5iQlU/view @rluble: Can you take look at this one. It is probably an API change in ModuleDefLoader and it might be an easy fix. - JSON Sample does not work since the yahoo search returns a 404 Can somebody please take a look at updating the JSON Sample to use a different service for the actual search? -Daniel -- 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/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiptX2h5qZ7DJg0XiZqbAGMfJJX_m8jT4%2BVDA9z1%3DeEF1Q%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAN%3DyUA3%3Damv3RHnN9%3DRcfpOmGOD35HXnQ9%2BmL9HkCU9CAu2QXw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
