Re: [gwt-contrib] Re: New JsInterop document

That is the old (and to be deleted) JsType annotation. The jsinterop.annotations.JsType still has isNative as per the spec Den onsdag den 9. december 2015 kl. 22.59.30 UTC+1 skrev Brandon Donnelson: > > I noticed that isNative has been removed and exists in the doc. > > >

Re: [gwt-contrib] Re: New JsInterop document

Turns out I imported the wrong JsType. Thanks for the help. On Wednesday, December 9, 2015 at 2:13:04 PM UTC-8, Rene Hangstrup Møller wrote: > > That is the old (and to be deleted) JsType annotation. The > jsinterop.annotations.JsType still has isNative as per the spec > > Den onsdag den 9.

Re: [gwt-contrib] Re: New JsInterop document

I noticed that isNative has been removed and exists in the doc. https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59 -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop

Re: [gwt-contrib] Re: New JsInterop document

On Wednesday, December 9, 2015 at 10:59:30 PM UTC+1, Brandon Donnelson wrote: > > I noticed that isNative has been removed and exists in the doc. > > > https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59 > This commit is about com.google.gwt.core.client.js.JsType

Re: [gwt-contrib] Re: New JsInterop document

I've been testing JsInterop for 'export java lib to js' use case and two things came up: 1. Annotations have RetentionPolicy.RUNTIME which means the library I'm exporting must have compile time dependency on gwt-user. There are 2 ways to fix it: change the retention to 'source' (AutoValue does

Re: [gwt-contrib] Re: New JsInterop document

We now produce a jsinterop-annotations artifact, but our deployment to Sonatype OSSRH is currently broken. -- 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

Re: [gwt-contrib] Re: New JsInterop document

On Sun, Dec 6, 2015 at 12:38 PM, Grzegorz Nowak wrote: > I've been testing JsInterop for 'export java lib to js' use case and two > things came up: > > 1. Annotations have RetentionPolicy.RUNTIME which means the library I'm > exporting must have compile time dependency

Re: [gwt-contrib] Re: New JsInterop document

I guess I can't put native JsInterop classes and interfaces in Java Collections ? I get a ClassCastException and I checked the official JsInterop documentation and couldn't find anthing about that ? On Saturday, November 21, 2015 at 5:02:13 AM UTC+1, Goktug Gokdogan wrote: > > dramaix@ is

Re: [gwt-contrib] Re: New JsInterop document

That's not fixed yet. Should be fixed before RC1. On Fri, Dec 4, 2015 at 7:23 AM, Ümit Seren wrote: > I guess I can't put native JsInterop classes and interfaces in Java > Collections ? > I get a ClassCastException and I checked the official JsInterop > documentation and

Re: [gwt-contrib] Re: New JsInterop document

dramaix@ is writing such a tool; that's how we are planning to generate Elemental2. On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov wrote: > And it would be nice to generate java code with new jsinterop annotations > based on typescript d.ts files. Dart team is going to

Re: [gwt-contrib] Re: New JsInterop document

Instead of JsArray, you can use Object[] or JsType[] (will be ready by 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly maps to number in javascript). On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley wrote: > We wrote our own RPC mechanism that is

[gwt-contrib] Re: New JsInterop document

We wrote our own RPC mechanism that is based entirely on JSON, mainly for performance reasons on mobile. The client works with JS Overlay representation of the server DTO objects. We have a tool that automatically generates the JSO's, Looking at the new interop spec's it would be really nice

Re: [gwt-contrib] Re: New JsInterop document

Great thanks, that makes it much clearer. On Tuesday, November 17, 2015 at 5:50:13 PM UTC+1, Goktug Gokdogan wrote: > > If the type is native, we don't generate code for the class we assume it > exists somewhere. If it is not native, we generate code for the class like > we do for every

Re: [gwt-contrib] Re: New JsInterop document

Your example is correct, this is the way to do. You can also add some logic to your object (for initialization for instance) by using overlay methods @JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object") public class Options { public String option1; public int option2; @JsOverlay

Re: [gwt-contrib] Re: New JsInterop document

> Options options = new Options().init("some string", 24); > Its not directly mentioned in the new spec document but I hope static methods are also valid for @JsOverlay? E.g. Options options = Options.create("some string", 24); -- J. -- You received this message because you are subscribed

Re: [gwt-contrib] Re: New JsInterop document

Instance methods, static methods and compile time constants can be marked with JsOverlay. Feel free to send a patch for updating the javadoc if it is not already there :) On Tue, Nov 17, 2015 at 4:18 AM, Jens wrote: > > Options options = new Options().init("some

Re: [gwt-contrib] Re: New JsInterop document

Seems to be work ;-) On Tuesday, November 17, 2015 at 1:18:27 PM UTC+1, Jens wrote: > > > Options options = new Options().init("some string", 24); >> > > Its not directly mentioned in the new spec document but I hope static > methods are also valid for @JsOverlay? E.g. > > Options options =

Re: [gwt-contrib] Re: New JsInterop document

If the type is native, we don't generate code for the class we assume it exists somewhere. If it is not native, we generate code for the class like we do for every other class. The best way to think about how jsinterop works is thinking with ES6 classes. @JsTypeclass X { static void m() { .. }

Re: [gwt-contrib] Re: New JsInterop document

Ok I can confirm that the issue was my fault. After moving everything to a JsTyp annotated classes, everything works fine. I have a last question regarding code size and the use if isNative=true. I guess isNative=true is preferred and will make sure that code size stays low by not exposing

Re: [gwt-contrib] Re: New JsInterop document

Ok, I think the issue regarding setLabels(String[] labels) is my fault. Previously I had an interface that was annotated with @JsType and a class that was implementing it and when I switched to the latest JS_RC JsInterop I re-created the implementing class from scratch but with empty

Re: [gwt-contrib] Re: New JsInterop document

Thanks for the info. AFAIK JSNI syntax will go away at some point. I guess I would then rely on a utility class to do that. One more question: Are there any restrictions regarding @JsProperty fields and Arrays ? somehow following thing dosn't work (it's not set on the object , stays

Re: [gwt-contrib] Re: New JsInterop document

On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren wrote: > Thanks for the info. > > AFAIK JSNI syntax will go away at some point. I guess I would then rely on > a utility class to do that. > > There is going to be a replacement for JSNI by supplying supplementary js files. So if

Re: [gwt-contrib] Re: New JsInterop document

Goktug, this is an example perfectly working with jsInteropMode=JS but not working with JS_RC : (Errors : Native JsType field 'String MyComponent.TAG' cannot have initializer & Native JsType method 'String MyComponent.getTagName()' should be native or abstract)

Re: [gwt-contrib] Re: New JsInterop document

I think there was a misunderstanding. You mentioned "if we support static methods we should support static fields as well" and I said both should NOT work without JsOverlay. It seems like your examples correctly gives an error for both static method and the static field because they don't have the

Re: [gwt-contrib] Re: New JsInterop document

On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren wrote: > Is there a way to add dynamic properties to a JsType without relying on > JSNI ? > > With the experimental JSInterop version I had following solution: > > @JsTypinterface Options { > >@JsProperty void getSomeProp();

Re: [gwt-contrib] Re: New JsInterop document

You could probably support Modules via a GWT linker. Generators and Async functions could be done by a GWT Generator/Linker combo + BabelJS. There's no real plans to support ES6 in GWT, but you could arrange enough hacks with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from

Re: [gwt-contrib] Re: New JsInterop document

Generally speaking J2CL seeks to support Java language features and in the process of doing so make use of modern ES6 features. When it comes to the separate topic of making advanced ES6 features (that don't exist in the Java language) available to J2CL users the path for that is via the JsInterop

Re: [gwt-contrib] Re: New JsInterop document

I think you might be able to get away with Async functions something like this: @JsFunction interface AsyncFunction { T execute(); } public class Foo { Promise fetchJson() { return Async.await(Xhr.fetch("/someJson")); // returns a Promise } } public class Async {

Re: [gwt-contrib] Re: New JsInterop document

Do you plan on supporting these features in j2cl in the future? On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote: > > > You could probably support Modules via a GWT linker. Generators and Async > functions could be done by a GWT Generator/Linker combo + BabelJS. There's >

[gwt-contrib] Re: New JsInterop document

A number of the new frameworks (Angular 2, Aurelia) are planning on using ES6 and ES7 features such as Modules, Decorators, Generators and Async functions etc. Are there plans to support these on the 2.x code base or would these only be supported by j2cl in the future? On Friday, October 23,

Re: [gwt-contrib] Re: New JsInterop document

Is there a way to add dynamic properties to a JsType without relying on JSNI ? With the experimental JSInterop version I had following solution: @JsTypinterface Options { @JsProperty void getSomeProp(); @JsProperty String getSomeProp2(); @JsProperty void setSomeProp2(String prop);

Re: [gwt-contrib] Re: New JsInterop document

Method overloading works in native JsType JsType(isNative=true) On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino wrote: > Seems that method overloading is not working anymore with JS_RC mode, it > was working in JS mode though: > > Example: > >boolean validate() >

Re: [gwt-contrib] Re: New JsInterop document

No plan to support through Java implementors, although there are plans to support varargs which would let you accomplish something similar. On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" wrote: > I see, it works, thanks. > > Any plan to work as well with gwt exported classes

Re: [gwt-contrib] Re: New JsInterop document

Seems that method overloading is not working anymore with JS_RC mode, it was working in JS mode though: Example: boolean validate() boolean validate(String foo) Is it a feature not implemented yet, or it is not in the specification? Thanks - Manolo On Mon, Nov 9, 2015 at 3:40 PM,

Re: [gwt-contrib] Re: New JsInterop document

I see, it works, thanks. Any plan to work as well with gwt exported classes ? On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix wrote: > Method overloading works in native JsType JsType(isNative=true) > > On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino

Re: [gwt-contrib] Re: New JsInterop document

var args sounds pretty good, but some kind of overloading based on the number of parameters like we had in gwt-exporter should cover many use cases, compiler could give an error (like it does now) when it sees two methods with the same-number-of-parameters signature. On Tue, Nov 10, 2015 at

Re: [gwt-contrib] Re: New JsInterop document

Another issue in the new implementation is that it's not supported any more static shared fields in JsType native interfaces, I think if we support static methods we should support static fields as well, or is there i any reason to prevent it ?. On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco

Re: [gwt-contrib] Re: New JsInterop document

In native types, the support for static methods are same as the support for static fields; only overlays are supported because we don't modify the native types. Can you give an example that works with static methods and doesn't work with static field but should work as well? What do you mean by

[gwt-contrib] Re: New JsInterop document

Goktug: Nice Work!! How can we handle constructors of native types that receive parameters? By Example Promise in JS: new Promise(*executor*); new Promise(function(resolve, reject) { ... }); I resolve with a static method and JSNI: public final static native Promise

[gwt-contrib] Re: New JsInterop document

Thanks Julien!!! This work fine!! El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan escribió: > > As we are getting close to 2.8 release I wrote a new document that is > concentrating on jsinterop features to be released in 2.8: > >

[gwt-contrib] Re: New JsInterop document

What about method overloading on Java side? Doesn't seem to be mentioned in the doc so I guess its not supported and we would need to rename methods on Java side? E.g. class Foo { @JsMethod(name = "send") public native void sendString(String s) @JsMethod(name = "send") public native

Re: [gwt-contrib] Re: New JsInterop document

Yes, no overloads in Java side as we don't automatically generate dispatch. Either you need to rename or you can create a send(Object) and dispatch manually to other methods. On Fri, Oct 23, 2015 at 1:57 AM, Jens wrote: > What about method overloading on Java side?