Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

On Fri, May 22, 2015 at 12:22 PM, Jens  wrote:

> Seems to look good. Seems pretty similar to the single @Js annotation
> version but reads better because of separate
> @JsMethod/@JsProperty/@JsConstrutor annotations and gives the possibility
> to add specific attributes to just one of them if ever needed.
>
> Two short questions:
>
> - JsConstrutor does not have a name attribute so maybe its worth
> documenting that you can not use JavaScript reserved words as (yes, ugly
> lower case) class names when @JsConstructor(export = true) is used?
>
>
We will have a check for this but I agree it is a good idea to document
this in javadoc.


> - Currently name and export attributes are repeated through
> @JsType/Constructor/Method/Property. Is there any reason why @JsNamespace
> stands alone? For consistency I would probably convert @JsNamespace into an
> attribute as well, especially if @JsNamespace can be used with all four
> annotations.
>
>
>
Export and name attributes are always valid to set while namespace can be
set on only static members. Also we need it so that we could set the
namespace on package-info file.

An alternative solution would be introducing JsPackage annotation to use
with package-info file and introduce namespace attribute where applicable.
That would be more consistent with the rest.


> -- J.
>
> --
> 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/bf832bd5-ae11-45eb-9421-bc73d5aff1a2%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 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%3DyUA3ubPeu-dZas3rs%2BtDnnVFeTRvXJur2BK2OciY9CbeMtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Jens]

Seems to look good. Seems pretty similar to the single @Js annotation 
version but reads better because of separate 
@JsMethod/@JsProperty/@JsConstrutor annotations and gives the possibility 
to add specific attributes to just one of them if ever needed.

Two short questions:

- JsConstrutor does not have a name attribute so maybe its worth 
documenting that you can not use JavaScript reserved words as (yes, ugly 
lower case) class names when @JsConstructor(export = true) is used?

- Currently name and export attributes are repeated through 
@JsType/Constructor/Method/Property. Is there any reason why @JsNamespace 
stands alone? For consistency I would probably convert @JsNamespace into an 
attribute as well, especially if @JsNamespace can be used with all four 
annotations.


-- J.

-- 
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/bf832bd5-ae11-45eb-9421-bc73d5aff1a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

Then +1 from me.

Marcin

On Fri, May 22, 2015 at 8:48 PM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Yes, that's correct.
>
> On Fri, May 22, 2015 at 2:43 AM, Marcin Okraszewski 
> wrote:
>
>> Hi,
>> It looks pretty readable to me. Actually my first reaction was also that
>> why export is default false, as initially I thought some of the annotations
>> were used for exporting. So I assume that if for instance I use some JS
>> library, then eg. @JsMethod(name="bar") would specify what JS method is
>> called, regardless of name in Java. Is it correct?
>>
>> Marcin
>>
>>
>> On Wednesday, 20 May 2015 00:18:14 UTC+2, Goktug Gokdogan wrote:
>>
>>> Thanks for the nice summary Ray.
>>>
>>> This is still work in progress but here is the tentative list of
>>> annotations and details of the new semantics. Please play with it and
>>> continue making suggestions.
>>>
>>> *@JsConstructor*
>>> JsConstructor marks a constructor so that it will be the constructor
>>> function for the JavaScript type. Note that, there could be only one
>>> JsConstructor in a type and all other constructors should be delegating to
>>> it.
>>>
>>> public @interface JsConstructor {
>>>   /**
>>>* If a constructor is exported, then it will be not be pruned by the
>>> compiler.
>>>*/
>>>   boolean export() default false;
>>> }
>>>
>>> *@JsMethod*
>>> JsMethod marks a method in a type as a method that will be directly
>>> translated into a JavaScript method without any obfuscation to its name.
>>> Note that, while instance members are slotted in the prototype, class
>>> members will be defined under the constructor function of the type.
>>>
>>> public @interface JsMethod {
>>>   /**
>>>* Customizes the name of the method in generated JavaScript. If not
>>> provided, the Java name will
>>>* be used.
>>>*/
>>>   String name() default "";
>>>
>>>   /**
>>>* If a method is exported, then it will be not be pruned by the
>>> compiler. Note that if the class
>>>* is pruned then instance members will also be pruned even they are
>>> exported (i.e. exporting
>>>* instance members doesn't prevent class pruning).
>>>*/
>>>   boolean export() default false;
>>> }
>>>
>>> *@JsProperty:*
>>> JsProperty marks a field in a type as a method that will be directly
>>> translated into a javascript property without any obfuscation to its name.
>>> If it is applied to a method, it will be treated as a property accessor.
>>> As a result, instead of translating method calls to JsProperty methods as
>>> method calls in JS, they will be translated as property lookups. When a
>>> JsProperty method implemented by a Java class, such methods will be
>>> generated as custom property setter and getter in JavaScript, hence the
>>> property access will trigger the execution of the matching getter or setter
>>> methods.
>>>
>>> JsProperty follows JavaBean style naming convention to extract the
>>> default property name. If the JavaBean convention is not followed, the name
>>> should be set explicitly. For example:
>>>   @JsProperty getX() or @JsProperty isX() translates as this.x
>>>   @JsProperty setX(int y) translates as this.x=y
>>>
>>> Note that, while non-static member are slotted in the prototype, static
>>> members will be defined under the constructor function of the type.
>>>
>>> public @interface JsProperty {
>>>   /**
>>>* Customizes the name of the member in generated javascript. If none
>>> is provided;
>>>* 
>>>* if it is field, the simple Java name will be used.
>>>* if it is a method, the name will be generated based on JavaBean
>>> conventions.
>>>*/
>>>   String name() default "";
>>>
>>>   /**
>>>* If a method is exported, then it will be not be pruned by the
>>> compiler. Note that if the class
>>>* is pruned then non-static members will also be pruned even they are
>>> exported (i.e. exporting
>>>* non-static methods doesn't prevent class pruning).
>>>*/
>>>   boolean export() default false;
>>> }
>>>
>>> *@JsType:*
>>> JsType is used to describe the JavaScript API of an object, either one
>>> that already exists from the external JavaScript environment, or one that
>>> will be accessible from the external JavaScript environment.
>>>
>>> Marking an object with JsType is similar to marking each public member
>>> of the class with {@link JsProperty}/{@link JsMethod}/{@link JsConstructor}
>>> respectively. In order for this to work correctly the JavaScript name needs
>>> to be unique for each member. Some unobvious ways to cause such name
>>> collisions are:
>>>  * Having method or constructor overloads.
>>>  * Using the same name for a method and a field.
>>>  * Shadowing a field from parent.
>>>
>>> A name collision needs to be avoided by providing a custom name (e.g.
>>> {@link JsProperty#name}) or
>>> by completely ignoring the member using {@link JsIgnore}.
>>>
>>> If the JsType is marked with a prototype reference, then classes 

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

Yes, that's correct.

On Fri, May 22, 2015 at 2:43 AM, Marcin Okraszewski 
wrote:

> Hi,
> It looks pretty readable to me. Actually my first reaction was also that
> why export is default false, as initially I thought some of the annotations
> were used for exporting. So I assume that if for instance I use some JS
> library, then eg. @JsMethod(name="bar") would specify what JS method is
> called, regardless of name in Java. Is it correct?
>
> Marcin
>
>
> On Wednesday, 20 May 2015 00:18:14 UTC+2, Goktug Gokdogan wrote:
>
>> Thanks for the nice summary Ray.
>>
>> This is still work in progress but here is the tentative list of
>> annotations and details of the new semantics. Please play with it and
>> continue making suggestions.
>>
>> *@JsConstructor*
>> JsConstructor marks a constructor so that it will be the constructor
>> function for the JavaScript type. Note that, there could be only one
>> JsConstructor in a type and all other constructors should be delegating to
>> it.
>>
>> public @interface JsConstructor {
>>   /**
>>* If a constructor is exported, then it will be not be pruned by the
>> compiler.
>>*/
>>   boolean export() default false;
>> }
>>
>> *@JsMethod*
>> JsMethod marks a method in a type as a method that will be directly
>> translated into a JavaScript method without any obfuscation to its name.
>> Note that, while instance members are slotted in the prototype, class
>> members will be defined under the constructor function of the type.
>>
>> public @interface JsMethod {
>>   /**
>>* Customizes the name of the method in generated JavaScript. If not
>> provided, the Java name will
>>* be used.
>>*/
>>   String name() default "";
>>
>>   /**
>>* If a method is exported, then it will be not be pruned by the
>> compiler. Note that if the class
>>* is pruned then instance members will also be pruned even they are
>> exported (i.e. exporting
>>* instance members doesn't prevent class pruning).
>>*/
>>   boolean export() default false;
>> }
>>
>> *@JsProperty:*
>> JsProperty marks a field in a type as a method that will be directly
>> translated into a javascript property without any obfuscation to its name.
>> If it is applied to a method, it will be treated as a property accessor.
>> As a result, instead of translating method calls to JsProperty methods as
>> method calls in JS, they will be translated as property lookups. When a
>> JsProperty method implemented by a Java class, such methods will be
>> generated as custom property setter and getter in JavaScript, hence the
>> property access will trigger the execution of the matching getter or setter
>> methods.
>>
>> JsProperty follows JavaBean style naming convention to extract the
>> default property name. If the JavaBean convention is not followed, the name
>> should be set explicitly. For example:
>>   @JsProperty getX() or @JsProperty isX() translates as this.x
>>   @JsProperty setX(int y) translates as this.x=y
>>
>> Note that, while non-static member are slotted in the prototype, static
>> members will be defined under the constructor function of the type.
>>
>> public @interface JsProperty {
>>   /**
>>* Customizes the name of the member in generated javascript. If none
>> is provided;
>>* 
>>* if it is field, the simple Java name will be used.
>>* if it is a method, the name will be generated based on JavaBean
>> conventions.
>>*/
>>   String name() default "";
>>
>>   /**
>>* If a method is exported, then it will be not be pruned by the
>> compiler. Note that if the class
>>* is pruned then non-static members will also be pruned even they are
>> exported (i.e. exporting
>>* non-static methods doesn't prevent class pruning).
>>*/
>>   boolean export() default false;
>> }
>>
>> *@JsType:*
>> JsType is used to describe the JavaScript API of an object, either one
>> that already exists from the external JavaScript environment, or one that
>> will be accessible from the external JavaScript environment.
>>
>> Marking an object with JsType is similar to marking each public member of
>> the class with {@link JsProperty}/{@link JsMethod}/{@link JsConstructor}
>> respectively. In order for this to work correctly the JavaScript name needs
>> to be unique for each member. Some unobvious ways to cause such name
>> collisions are:
>>  * Having method or constructor overloads.
>>  * Using the same name for a method and a field.
>>  * Shadowing a field from parent.
>>
>> A name collision needs to be avoided by providing a custom name (e.g.
>> {@link JsProperty#name}) or
>> by completely ignoring the member using {@link JsIgnore}.
>>
>> If the JsType is marked with a prototype reference, then classes extend
>> from this will use the specified prototype as opposed to the ordinary one
>> (e.g. java.lang.Object).
>>
>> JsTypes act like JavaScriptObject in terms of castability, except when a
>> prototype is specified, in which case, cast checks and instanceof checks
>> will be dele

[gwt-contrib] stack trace on master calling List.sort

[Stephen Haberman]

Sorry for the cheap bug report, but on GWT master, the innocent looking:

final List f = newArrayList();
f.sort((a, b) -> a.compareTo(b));

Will result in a compiler NPE:

Caused by: java.lang.NullPointerException
at com.google.gwt.dev.jjs.ast.JMethod.getJsniSignature(JMethod.java:518)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.computeName(ControlFlowRecorder.java:49)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.processMethodCall(ControlFlowRecorder.java:197)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.visit(ControlFlowRecorder.java:151)
at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:248)
at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)

I get the root cause is that List.sort is a new JDK8 method that is not
implemented, which is fine, I’ll use Collections.sort and everything is
fine, but I was just surprised to see the compiler actually stack trace vs.
fail with a nicer compiler error.

Feel free to ignore this if this really is expected/unavoidable; admittedly
I don’t know what the previous behavior was in this situation of a
super-sourced class missing a method.

- Stephen
​

-- 
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/CANnRKuV2_m9%3DVap4oHHJuo5jtsA5_20exya0yHx%3DvAvtePFtrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

Hi,
It looks pretty readable to me. Actually my first reaction was also that 
why export is default false, as initially I thought some of the annotations 
were used for exporting. So I assume that if for instance I use some JS 
library, then eg. @JsMethod(name="bar") would specify what JS method is 
called, regardless of name in Java. Is it correct?

Marcin


On Wednesday, 20 May 2015 00:18:14 UTC+2, Goktug Gokdogan wrote:
>
> Thanks for the nice summary Ray.
>
> This is still work in progress but here is the tentative list of 
> annotations and details of the new semantics. Please play with it and 
> continue making suggestions.
>
> *@JsConstructor*
> JsConstructor marks a constructor so that it will be the constructor 
> function for the JavaScript type. Note that, there could be only one 
> JsConstructor in a type and all other constructors should be delegating to 
> it.
>
> public @interface JsConstructor {
>   /**
>* If a constructor is exported, then it will be not be pruned by the 
> compiler.
>*/
>   boolean export() default false;
> }
>
> *@JsMethod*
> JsMethod marks a method in a type as a method that will be directly 
> translated into a JavaScript method without any obfuscation to its name. 
> Note that, while instance members are slotted in the prototype, class 
> members will be defined under the constructor function of the type.
>
> public @interface JsMethod {
>   /**
>* Customizes the name of the method in generated JavaScript. If not 
> provided, the Java name will
>* be used.
>*/
>   String name() default "";
>
>   /**
>* If a method is exported, then it will be not be pruned by the 
> compiler. Note that if the class
>* is pruned then instance members will also be pruned even they are 
> exported (i.e. exporting
>* instance members doesn't prevent class pruning).
>*/
>   boolean export() default false;
> }
>
> *@JsProperty:*
> JsProperty marks a field in a type as a method that will be directly 
> translated into a javascript property without any obfuscation to its name.
> If it is applied to a method, it will be treated as a property accessor. 
> As a result, instead of translating method calls to JsProperty methods as 
> method calls in JS, they will be translated as property lookups. When a 
> JsProperty method implemented by a Java class, such methods will be 
> generated as custom property setter and getter in JavaScript, hence the 
> property access will trigger the execution of the matching getter or setter 
> methods.
>
> JsProperty follows JavaBean style naming convention to extract the default 
> property name. If the JavaBean convention is not followed, the name should 
> be set explicitly. For example:
>   @JsProperty getX() or @JsProperty isX() translates as this.x
>   @JsProperty setX(int y) translates as this.x=y
>
> Note that, while non-static member are slotted in the prototype, static 
> members will be defined under the constructor function of the type.
>
> public @interface JsProperty {
>   /**
>* Customizes the name of the member in generated javascript. If none is 
> provided;
>* 
>* if it is field, the simple Java name will be used.
>* if it is a method, the name will be generated based on JavaBean 
> conventions.
>*/
>   String name() default "";
>
>   /**
>* If a method is exported, then it will be not be pruned by the 
> compiler. Note that if the class
>* is pruned then non-static members will also be pruned even they are 
> exported (i.e. exporting
>* non-static methods doesn't prevent class pruning).
>*/
>   boolean export() default false;
> }
>
> *@JsType:*
> JsType is used to describe the JavaScript API of an object, either one 
> that already exists from the external JavaScript environment, or one that 
> will be accessible from the external JavaScript environment.
>
> Marking an object with JsType is similar to marking each public member of 
> the class with {@link JsProperty}/{@link JsMethod}/{@link JsConstructor} 
> respectively. In order for this to work correctly the JavaScript name needs 
> to be unique for each member. Some unobvious ways to cause such name 
> collisions are:
>  * Having method or constructor overloads.
>  * Using the same name for a method and a field.
>  * Shadowing a field from parent.
>
> A name collision needs to be avoided by providing a custom name (e.g. 
> {@link JsProperty#name}) or
> by completely ignoring the member using {@link JsIgnore}.
>
> If the JsType is marked with a prototype reference, then classes extend 
> from this will use the specified prototype as opposed to the ordinary one 
> (e.g. java.lang.Object).
>
> JsTypes act like JavaScriptObject in terms of castability, except when a 
> prototype is specified, in which case, cast checks and instanceof checks 
> will be delegated to the native JavaScript instanceof operator.
>
> public @interface JsType {
>   /**
>* Customizes the name of the type in generated javascript. If not 
> provid

Re: [gwt-contrib] Re: Experience with JsInterop status

[Marcin Okraszewski]

Hi,
It works like a charm now! 

For the event.currentTarget, yes this is true, and I also pointed it in 
this thread earlier 
https://groups.google.com/forum/#!msg/google-web-toolkit-contributors/QrkNflMKe9E/cyhaHJGwtV8J
 
. Actually good to know ES6 it won't work lambdas too, which should mean 
overriding "this" should fade out in some future. 

Marcin

On Friday, 22 May 2015 03:49:40 UTC+2, Goktug Gokdogan wrote:
>
> Ok, JsFunction call/apply issue should be fixed as of 
> https://gwt-review.googlesource.com/#/c/12810/. Can you verify that for 
> me?
>
> You cannot still access JQuery bound 'this'. However note that the same 
> issue also exists for ES6 arrow functions.
> According to [1] this could be worked around in JQuery's case via 
> event.currentTarget. 
>
> This required some restrictions and I put others as well so that one day 
> we can generate a completely real function from it.
>
> [1] 
> http://stackoverflow.com/questions/27670401/using-jquery-this-with-traceur-es6-harmony-arrow-functions-lexical-this-bi
>
> On Wed, Apr 29, 2015 at 2:19 PM, Goktug Gokdogan  > wrote:
>
>> I think this could be handled by @JsConvert that is specific for jQuery 
>> instead of a custom annotation.
>>
>> On Wed, Apr 29, 2015 at 1:02 AM, 'Ray Cromwell' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com > wrote:
>>
>>>
>>> Lambda's are inner classes, so there is always a 'this' bound to the 
>>> generated instance, otherwise, the handling method wouldn't be invokable. 
>>> Imagine if you were implementing this with JSNI:
>>>
>>> class HandlerWithThisImpl implements HandlerWithThis {
>>>public void onEvent(Element target, Event e) { ... }
>>> }
>>>
>>> You'd have to write a wrapper that did this:
>>>
>>> static native JavaScriptObject makeFunction(HandlerWithThis impl) /*-{
>>> return function(e) { impl.@onEvent(*)(this, e); }
>>> }-*/;
>>>
>>> But to make referential integrity work so that a HandlerWithThis passing 
>>> into JS and back into Java always converts to the same function and object 
>>> reference, you'd have to generate a lot more boilerplate.
>>>
>>>
>>> Instead, to make @JsThis work efficiently, you'd have to do something 
>>> like this with the magic makeLambdaFunction
>>>
>>> /**
>>>  * Create a function that applies the specified samMethod on itself, and 
>>> whose __proto__ points to
>>>  * instance.
>>>  */
>>> public static native JavaScriptObject makeLambdaFunction(JavaScriptObject 
>>> samMethod,
>>> JavaScriptObject instance, int jsThisArgPosition) /*-{
>>>   var lambda = function() {
>>> var args = arguments;
>>> if (jsThisArgPosition >= 0) {
>>>   args.splice(jsThisArgPosition, 0, this);
>>> }
>>> return samMethod.apply(lambda, args);
>>>   }
>>>   lambda.__proto__ = instance;
>>>   return lambda;
>>> }-*/;
>>>
>>> It's feasible, but I think the community needs to chime in.  IIRC, the 
>>> DOM APIs have changed over the years to include the context as a field of 
>>> the event argument. 
>>>
>>> But perhaps when you look at libraries like Ember, Angular, React, 
>>> Backbone, et al, all common is it for the 'this' to be bound, passing this 
>>> explicitly as a parameter?
>>>
>>> Typical Google coding style internally is if you want to use this, you 
>>> use Function.bind() to set it to what you want when you pass in a handler 
>>> function to something.
>>>
>>> Rebinding this from the calling context seems iffy and dangerous when 
>>> you think about Java code.
>>>
>>>
>>>
>>>
>>> On Wed, Apr 29, 2015 at 12:32 AM, Marcin Okraszewski >> > wrote:
>>>

>>1. @JsFunction exported to JS doesn't have apply() and call()
>> operations. Apply() is used by JQuery (2.1.3) to call callbacks, 
>>so basically it wasn't possible to add handlers using JQuery. See 
>> other 
>>thread on this: 
>>https://groups.google.com/forum/#!topic/google-web-toolkit/PHtfLTSAJDM
>> 
>>
>> Pretty interesting how to model that JQuery callback with JsInterop. 
> Basically when you do $("p").click(handler) then JQuery sets "this" for 
> the 
> handler to the element the event occurred on so you can do 
>
> $("p").click(function() {
>$(this).slideUp(); // slides the clicked p element up
> });
>
> I think you can't really do that with just JsInterop. I think your 
> Java callback must be JQueryCallback.exec(Element elem, Event e) and you 
> have to use JSNI to create a pure JS function that passes "this" as 
> "elem" 
> to the JQueryCallback.
>


 This is definitely problematic. I didn't give it too much though, but I 
 think it would be great if we could opt-in to get the *this* from 
 JavaScript. Something like this: 

 @JsFunction
 public interface HandlerWithThis {
public void onEvent(*@JsThis* Element target, Event e);
 }

 If you need the JavaScript *this,* then you just add it as parameter