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 JsArray<T> {
> 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 <[email protected]
> <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 loadTexture(String url) { return
> >> js("$wnd.THREE.ImageUtils.loadTexture($0)", url); }
> >> }
> >>
> >> ImageUtils.loadTexture(url);
> >>
> >>
> >>
> >> On Sat, Oct 4, 2014 at 8:18 AM, confile <[email protected]>
> >> wrote:
> >> > Consider the following static JavaScript function:
> >> >
> >> > THREE.ImageUtils = {
> >> > loadTexture: function (url) { ... }
> >> >
> >> > }
> >> >
> >> > The way I use to create the static function with JsInterop is to
> create
> >> > an
> >> > interface for ImageUtils and then create an inner abstract class
> >> > MyStatic
> >> > which contains the static methods implemented with JSNI.
> >> >
> >> > Here is an example of the above class:
> >> >
> >> > @JsType
> >> > public interface ImageUtils {
> >> >
> >> > public static abstract class MyStatic {
> >> >
> >> > public static native Texture create(String url) /*-{
> >> > return new $wnd.THREE.ImageUtils.loadTexture(url);
> >> > }-*/;
> >> > }
> >> >
> >> > }
> >> >
> >> >
> >> > I don't think this is the best solution. Is there a better way to
> handle
> >> > static functions with JsInterop?
> >> >
> >> > --
> >> > 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 [email protected]
> <javascript:>.
> >> > To view this discussion on the web visit
> >> >
> >> >
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8f6cf42a-2910-4536-a2f7-1ae2d55422ac%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 [email protected]
> <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/51be727d-0003-425b-9040-bd3c8529ddd1%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e40493a9-b890-47b0-ad31-5cd4e9c28a46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
