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. dec
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.
>
>
> https://github.com/gwtp
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
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 recei
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 on gwt-user. There are 2 wa
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 g
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
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 couldn't find anthing a
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 w
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 implement such tool,
> prob
And it would be nice to generate java code with new jsinterop annotations
based on typescript d.ts files. Dart team is going to implement such tool,
probably it can be adopted for GWT as
well: https://github.com/dart-lang/sdk/issues/24874
On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Go
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 based entirely on JSON, ma
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 fo
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 other
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() { .. }
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 string", 24);
>>
>
> Its not dire
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 = Opt
> 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
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
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 th
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 function
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 you have a class with J
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
undefi
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
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)
@com.google.gwt.core.client.js.Js
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 {
@MustBeInline
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
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
> no
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
ES6
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,
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();
>
>@JsProperty Strin
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);
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
"st
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 Moñ
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 5:59
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 ?
>
> On Tue, Nov 10
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
> wrote:
>
>> Seems that method over
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()
>boolean validate(S
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, Cristi
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:
>
> https://docs.google.com/document/d/10fmlEYIH
Create a native JsType (isNative=true) named Promise with namespace set to
GLOBAL and define both constructors. It should work.
@JsType(isNative = true, namespace = JsPackage.GLOBAL)
public class Promise {
public Promise(PromiseFn fn){};
}
On Mon, Nov 9, 2015 at 2:57 PM Cristian Rinaldi wr
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 createP
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? Doesn't seem to be mentioned
>
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 voi
44 matches
Mail list logo