Experimental release of Elemental2

3,161 views
Skip to first unread message

Julien Dramaix

unread,
Jun 29, 2016, 8:23:51 PM6/29/16
to google-web-toolkit-contributors

A new experimental version of Elemental2 using the new JsInterop specification has been pushed on Sonatype today.


You can try it by downloading the jar file or adding this following maven dependency:


<dependency>

 <groupId>com.google.gwt</groupId>

 <artifactId>elemental2-experimental</artifactId>

 <version>16-06-30</version>

</dependency>


Then, inherits the elemental2 module:


<inherits name="elemental2" />


This experimental version works only with the last 2.8-snapshot release of GWT.


The goal of this release is to get feedback so don’t hesitate to report any bugs, issues, concerns you have on this mailing list.


Important note: This is an experimental release and without doubt the future updates until the final release are going to break code!  


- Julien


James Horsley

unread,
Jun 30, 2016, 5:59:55 AM6/30/16
to google-web-toolkit-contributors
This is brilliant. Thanks for sharing the experimental version!!!

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABXeq2Q%3DuH8beWj4tiG28tycASsJxK8mnxxNPZnEykUeTcMWXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Matic Petek

unread,
Jun 30, 2016, 6:15:12 AM6/30/16
to GWT Contributors
Hi,
  I would be nice If you could publish simple example how to start using it. 
Regards,
   Matic

Julien Dramaix

unread,
Jun 30, 2016, 7:16:28 AM6/30/16
to GWT Contributors
I'll try to find some time next week for uploading examples on my github account.

A simple example could be:
package elemental.sample.simple;

import static elemental2.Global.alert;
import static elemental2.Global.document;

import com.google.gwt.core.client.EntryPoint;

import elemental2.Event;
import elemental2.EventListener;
import elemental2.HTMLButtonElement;

public class SimpleApp implements EntryPoint{
  public void onModuleLoad() {
    final HTMLButtonElement button = (HTMLButtonElement) document.createElement("button");
    button.textContent = "Click me";
    button.addEventListener(
        "click",
        new EventListener() {
          @Override
          public void handleEvent(Event evt) {
            button.parentNode.removeChild(button);
            alert("Button has been removed.");
          }
        });
    document.body.appendChild(button);
  }
}
Elemental2.Global can be considered as the entry point of the library. It gathers all methods/fields available from the global scope (but not the window API).

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%40googlegroups.com.

Ray Cromwell

unread,
Jun 30, 2016, 2:21:55 PM6/30/16
to google-web-toolkit-contributors
should be able to make this a little tighter:

button.addEventListener("click", (evt) -> {
button.parentNode.removeChild(button); alert("Button has been
removed."); });

:)
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%40mail.gmail.com.

Ignacio Baca Moreno-Torres

unread,
Jun 30, 2016, 6:03:06 PM6/30/16
to GWT Contributors
I just applied elemental2 to this simple drang&drop and FileReader showcase (https://github.com/ibaca/dndfiles-gwt/blob/master/src/main/java/dndfiles/client/DndFiles.java). Elemental2 looks good, but I think that JsInterop still a bit... unpredictable. The project compiles correctly, but the codeserver fails, pruning/ignoring some methods. Or maybe I do not set the generateJsInteropExports correctly... not sure, but even if this is the problem, I'm still confusing why I need this flag if I'm not exporting anything. If I do not set this flag, the project do not work (some lambdas are pruned).
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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

Goktug Gokdogan

unread,
Jun 30, 2016, 6:16:34 PM6/30/16
to google-web-toolkit-contributors
You are probably missing the flag.
In this particular situation you are implementing a native JsType and that is considered a form exporting in current compiler and hence affected by the flag. I know that is surprising and it will be fixed in https://gwt-review.googlesource.com/#/c/15193/ (which will be submitted before the final release).

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/08b1f7b2-3682-4c83-977d-79c729cc2796%40googlegroups.com.

Ignacio Baca Moreno-Torres

unread,
Jul 1, 2016, 2:42:35 AM7/1/16
to GWT Contributors
Yep, not sure why... but I just try again and the parameter is used correctly by the codeserver, so it works as you said. When you said 'you are implementing a native JsType' you are talking about the JsFunction callbacks, isn't it? The issue said 'do not honor' so looks like the opposite direction (I mean, 'do not honor' is what is happening before issue is fixed or what should happen after the issue is fixed). To confirm, will this issue make this native JsFunction callbacks works without the export flag?
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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

--
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+unsubscribe@googlegroups.com.

Goktug Gokdogan

unread,
Jul 1, 2016, 4:33:22 AM7/1/16
to google-web-toolkit-contributors
On Thu, Jun 30, 2016 at 11:42 PM, Ignacio Baca Moreno-Torres <ign...@bacamt.com> wrote:
Yep, not sure why... but I just try again and the parameter is used correctly by the codeserver, so it works as you said. When you said 'you are implementing a native JsType' you are talking about the JsFunction callbacks, isn't it?

No, I'm talking about JsType(isNative=true). The lambda in your code implements EventListener which is a native JsType interface; not a JsFunction.

 
The issue said 'do not honor' so looks like the opposite direction (I mean, 'do not honor' is what is happening before issue is fixed or what should happen after the issue is fixed).

Yes, the patch description is not accurate. It stops honoring non-native JsType names in SDM to detect missing flag early on. In addition to that, it also makes sure that if you are implementing  a native JsType, it works with or without the flag. The description doesn't capture this part.
 
To confirm, will this issue make this native JsFunction callbacks works without the export flag?


JsFunction implementations already work with or without the flag. The patch will also make sure native JsType implementations to work with or without the flag.
So if you are using elemental, you won't need the flag (more common).
If you are exporting a Java API to be used by some JavaScript, you will need the flag (less common).

 
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e885d86d-cb93-4f4e-a086-f0e2ea803d27%40googlegroups.com.

Ignacio Baca Moreno-Torres

unread,
Jul 1, 2016, 6:10:04 AM7/1/16
to GWT Contributors
Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%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

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

Ignacio Baca Moreno-Torres

unread,
Jul 1, 2016, 6:12:01 AM7/1/16
to GWT Contributors
JsType example is: elemental2.EventListener.

Jens

unread,
Jul 1, 2016, 6:39:26 AM7/1/16
to GWT Contributors

Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?

I think its the result of definition of EventTarget.addEventListener():

listener - The object that receives a notification (an object that implements the Event interface) when an event of the specified type occurs. This must be an object implementing the EventListener interface, or simply a JavaScript function.

The EventListener interface is a defined API and thus a @JsType(isNative = true) interface has been generated. But to conform to "or simply a JavaScript function" there is also an AddEventListenerCallback that is a @JsFunction. Not sure if this distinction has any real value, in a hand coded elemental2 I would have only created a @JsFunction interface EventListener

-- J.

Goktug Gokdogan

unread,
Jul 1, 2016, 10:38:00 PM7/1/16
to google-web-toolkit-contributors
Closure extern definition uses a union type here:

So it accepts either EventListener interface or a function.

When we see a union type, we generate overloads for each type so Elemental should provide overloads that includes both. And it seems like it does. If not please let us know.

--
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-co...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.

Manuel Carrasco Moñino

unread,
Jul 2, 2016, 5:07:16 PM7/2/16
to google-web-toolkit-contributors
I'm wondering if it would be possible to have type-safe convenience methods for creating elements, so as the user does not have to provide the string tag name, nor cast the object, maybe something like :

HTMLButtonElement button = HTMLButtonElement.createElement();

instead of

HTMLButtonElement button = (HTMLButtonElement) document.createElement("button");


To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%40mail.gmail.com.

Ignacio Baca Moreno-Torres

unread,
Jul 2, 2016, 5:50:15 PM7/2/16
to google-web-toolkit-contributors
+1 to add some type-safe, in my current mini-project (almost 50 lines of code) there are 5 cast! 2 elements, 2 events and 1 event target... the event target is mandatory, but the events and elements will be nice to be type-safe.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsU1UZgkh3cjG1HPkpRBJfaiEh631fq9WdS_RQg8Z_Leg%40mail.gmail.com.

Paul Stockley

unread,
Jul 2, 2016, 9:13:17 PM7/2/16
to GWT Contributors
Would it be possible to break the project into a few packages? It would make it easier to find things.

Jakob Jarosch

unread,
Jul 3, 2016, 7:18:28 AM7/3/16
to GWT Contributors
It seems that the deployed dependency is inconsistent.
The pom.xml says "elemental-experimental" with version "2016-06-30".
But the dependency is available as "elemental2-experimental" with version "16-06-30".
So gradle is not able to resolve the dependency.

Warning:project ':frontend': Web Facets/Artifacts will not be configured properly
Details: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':frontend:runtime'.
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.
Required by:
    itdidea:frontend:unspecified
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.
Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.MetaDataParseException: inconsistent module metadata found. Descriptor: com.google.gwt:elemental-experimental:2016-06-29 Errors: bad module name: expected='elemental2-experimental' found='elemental-experimental'
bad version: expected='16-06-30' found='2016-06-29'

- Jakob


On Thursday, June 30, 2016 at 2:23:51 AM UTC+2, Julien Dramaix wrote:

Thomas Broyer

unread,
Jul 3, 2016, 7:52:54 AM7/3/16
to GWT Contributors


On Sunday, July 3, 2016 at 1:18:28 PM UTC+2, Jakob Jarosch wrote:
It seems that the deployed dependency is inconsistent.
The pom.xml says "elemental-experimental" with version "2016-06-30".
But the dependency is available as "elemental2-experimental" with version "16-06-30".

Wow, and Sonatype let it go in?! Looks like they need better checks.
 
So gradle is not able to resolve the dependency.

Warning:project ':frontend': Web Facets/Artifacts will not be configured properly
Details: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':frontend:runtime'.
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.
Required by:
    itdidea:frontend:unspecified
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve com.google.gwt:elemental2-experimental:16-06-30.
Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.MetaDataParseException: inconsistent module metadata found. Descriptor: com.google.gwt:elemental-experimental:2016-06-29 Errors: bad module name: expected='elemental2-experimental' found='elemental-experimental'
bad version: expected='16-06-30' found='2016-06-29'

Fortunately, Gradle is flexible enough.
Because elemental2-experimental has no dependency, I think you can use 'com.google.gwt:elemental2-experimental:16-06-30@jar', or alternatively use a "client module" with the module('com.google.gwt:elemental2-experimental:16-06-30') notation (difference with the "@jar" is that you can declare dependencies of the module, thereby replacing the bad POM with your own module definition). 

Goktug Gokdogan

unread,
Jul 4, 2016, 3:46:44 AM7/4/16
to google-web-toolkit-contributors
Elemental2 currently purely driven by the JavaScript extern files. So it is not trivial. Maybe a later version could include some kind of type extension.
For now perhaps we can improve the generated code to use generics so you don't need to cast but we cannot modify the API.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsU1UZgkh3cjG1HPkpRBJfaiEh631fq9WdS_RQg8Z_Leg%40mail.gmail.com.

Goktug Gokdogan

unread,
Jul 4, 2016, 3:46:59 AM7/4/16
to google-web-toolkit-contributors
We will look into that.

On Sat, Jul 2, 2016 at 6:13 PM, Paul Stockley <pstoc...@gmail.com> wrote:
Would it be possible to break the project into a few packages? It would make it easier to find things.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/127fd7d4-56ab-407e-9981-1da8d2d91a91%40googlegroups.com.

Julien Dramaix

unread,
Jul 4, 2016, 8:32:16 AM7/4/16
to GWT Contributors
yes, we are thinking about that. We would like also to add a feature checking system.
 AFAIC, I think this kind of wrapper code should be part of a separate library using elemental. I would like that elemental stays "close to the metal".
But we don't have decided anything yet now.


On Saturday, July 2, 2016 at 11:07:16 PM UTC+2, Manuel Carrasco Moñino wrote:
I'm wondering if it would be possible to have type-safe convenience methods for creating elements, so as the user does not have to provide the string tag name, nor cast the object, maybe something like :

HTMLButtonElement button = HTMLButtonElement.createElement();

instead of

HTMLButtonElement button = (HTMLButtonElement) document.createElement("button");



El sáb., 2 jul. 2016 a las 4:38, 'Goktug Gokdogan' via GWT Contributors (<google-web-toolkit-contri...@googlegroups.com>) escribió:
Closure extern definition uses a union type here:

So it accepts either EventListener interface or a function.

When we see a union type, we generate overloads for each type so Elemental should provide overloads that includes both. And it seems like it does. If not please let us know.
On Fri, Jul 1, 2016 at 3:39 AM, Jens <jens.ne...@gmail.com> wrote:

Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?

I think its the result of definition of EventTarget.addEventListener():

listener - The object that receives a notification (an object that implements the Event interface) when an event of the specified type occurs. This must be an object implementing the EventListener interface, or simply a JavaScript function.

The EventListener interface is a defined API and thus a @JsType(isNative = true) interface has been generated. But to conform to "or simply a JavaScript function" there is also an AddEventListenerCallback that is a @JsFunction. Not sure if this distinction has any real value, in a hand coded elemental2 I would have only created a @JsFunction interface EventListener

-- 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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

Julien Dramaix

unread,
Jul 4, 2016, 8:33:23 AM7/4/16
to GWT Contributors
yep it's planned

Julien Dramaix

unread,
Jul 4, 2016, 8:35:22 AM7/4/16
to GWT Contributors
I'm fixing my script in order to avoid that for the next release.

Thanks for the bug reporting!


On Sunday, July 3, 2016 at 1:18:28 PM UTC+2, Jakob Jarosch wrote:

Kalle Persson

unread,
Jul 4, 2016, 9:24:20 AM7/4/16
to GWT Contributors
So I guess this is also the reason for why e.g. Int32Array returns double instead of int?

Also, would it be possible / make sense to make CanvasRenderingContext2D and WebGLRenderingContext extend NativeObject?
Right now, as HTMLCanvasElement.getContext(String contextId) returns a NativeObject I have to do things like this when getting the context:

context_ = (CanvasRenderingContext2D) (Object) canvas.getContext("2d")

It works but it feels wrong. Or am I just missing something obvious?

On Monday, July 4, 2016 at 9:46:44 AM UTC+2, Goktug Gokdogan wrote:
Elemental2 currently purely driven by the JavaScript extern files. So it is not trivial. Maybe a later version could include some kind of type extension.
For now perhaps we can improve the generated code to use generics so you don't need to cast but we cannot modify the API.
On Sat, Jul 2, 2016 at 2:07 PM, Manuel Carrasco Moñino <man...@apache.org> wrote:
I'm wondering if it would be possible to have type-safe convenience methods for creating elements, so as the user does not have to provide the string tag name, nor cast the object, maybe something like :

HTMLButtonElement button = HTMLButtonElement.createElement();

instead of

HTMLButtonElement button = (HTMLButtonElement) document.createElement("button");



El sáb., 2 jul. 2016 a las 4:38, 'Goktug Gokdogan' via GWT Contributors (<google-web-toolkit-contri...@googlegroups.com>) escribió:
Closure extern definition uses a union type here:

So it accepts either EventListener interface or a function.

When we see a union type, we generate overloads for each type so Elemental should provide overloads that includes both. And it seems like it does. If not please let us know.
On Fri, Jul 1, 2016 at 3:39 AM, Jens <jens.ne...@gmail.com> wrote:

Thanks, now makes sense. I get confused with the JsFunction JsType(native) because elemental2 has some callbacks as JsFunction and others as JsType(native), now an actual elemental2 question; what criteria is used to apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of JsType (ex. elemental2.JsType)?

I think its the result of definition of EventTarget.addEventListener():

listener - The object that receives a notification (an object that implements the Event interface) when an event of the specified type occurs. This must be an object implementing the EventListener interface, or simply a JavaScript function.

The EventListener interface is a defined API and thus a @JsType(isNative = true) interface has been generated. But to conform to "or simply a JavaScript function" there is also an AddEventListenerCallback that is a @JsFunction. Not sure if this distinction has any real value, in a hand coded elemental2 I would have only created a @JsFunction interface EventListener

-- 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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

Julien Dramaix

unread,
Jul 4, 2016, 10:15:22 AM7/4/16
to GWT Contributors
> So I guess this is also the reason for why e.g. Int32Array returns double instead of int?
yes we just have the information that it's a number, so we convert that to double. We should be able to improve the number conversion before the final release.

> Right now, as HTMLCanvasElement.getContext(String contextId) returns a NativeObject I have to do things like this when getting the context:

This is an isue we are aware of. In the next release, Object will be used instead of NativeObject.



To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/023e92c6-8f9f-41b4-8203-369b82499d7f%40googlegroups.com.

Paul Stockley

unread,
Jul 4, 2016, 11:10:32 AM7/4/16
to GWT Contributors
I do think we should have another library that builds on Elemental2. While browser compatibility is a lot better, it still isn't perfect and we need  somewhere to collect workarounds for specific issues and add helper functions to make working with the library easier.

Jens

unread,
Jul 4, 2016, 12:32:23 PM7/4/16
to GWT Contributors

I do think we should have another library that builds on Elemental2. While browser compatibility is a lot better, it still isn't perfect and we need  somewhere to collect workarounds for specific issues and add helper functions to make working with the library easier.

But then you have the GWT overhead on top of it again. But I tend to agree that a purely generated API can never be that nice to use as a hand crafted one. I have only taken a very brief look at the generated code of the elemental2 snapshot build but I think my major points are:

- vendor prefixes. Sticking to standard API and asking devs to polyfill them if needed sounds better to me. Avoids potential API duplication.
- only doubles while int would make sense here and there
- no use of generics and enums
- no packages. Would be nice to have things like dom, crypto, promise, audio, webgl, etc.
- often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate.
- obviously no JavaDoc, but it would be nice to have. Especially for people working in a no-internet environment.
- edge cases like EventTarget.addEventListener(EventListener) and EventTarget.addEventListener(AddEventListenerListenerCallback) that should be cleaned up

Maybe it is worth thinking about providing some patch files in addition to the generator to fix some stuff that are hard to fix inside the elemental2 generator. Given that existing non-prefixed API does not change these patch files should be pretty stable and always applicable.

-- J.

Julien Dramaix

unread,
Jul 4, 2016, 1:55:39 PM7/4/16
to GWT Contributors
> - only doubles while int would make sense here and there
we are aware of that. That should be solved before the first release

> - no use of generics and enums
generics are used (look at NativeArray ot HtmlCollection). Enums not yet

> - no packages. Would be nice to have things like dom, crypto, promise, audio, webgl, etc.
it's planned

> - often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate.

if a method "getFoo" can return different types "string or Foo", we create different methods :
public Object getFoo();
public String getFooAsString();
public Foo getFooAsFoo();

In the future there will be javadoc above the methods mentioning these links between a set of methods.

> - obviously no JavaDoc, but it would be nice to have. Especially for people working in a no-internet environment.
As mentioned above, it's planned

> - edge cases like EventTarget.addEventListener(EventListener) and EventTarget.addEventListener(AddEventListenerListenerCallback) that should be cleaned up
I don't think we will clean that up. At least it's not planned.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%40googlegroups.com.

Jens

unread,
Jul 4, 2016, 3:05:04 PM7/4/16
to GWT Contributors

> - often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate.

if a method "getFoo" can return different types "string or Foo", we create different methods :
public Object getFoo();
public String getFooAsString();
public Foo getFooAsFoo();

In the future there will be javadoc above the methods mentioning these links between a set of methods.

What about methods that do not return different types and sometimes even should return void? For example 

void Window.alert(String)
void Window.focus()
long Date.setDate(int)

They all return Object currently.

-- J.

Julien Dramaix

unread,
Jul 4, 2016, 3:26:02 PM7/4/16
to GWT Contributors
This is a bug :)
That should be void and not object.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa7580d3-f355-44e1-a923-c588b3c6da45%40googlegroups.com.

Steve Andrews

unread,
Jul 21, 2016, 10:34:19 AM7/21/16
to GWT Contributors
I've been trying out the new Elemental and have been having trouble with EventListener. I'm on the latest GWT Snapshot (2.8.0-20160721.060317-297). It seems that the EventListener gets compiled out unless I use the Node.AddEventListenerListenerCallback function. Example:

searchButton.addEventListener("click",e -> doSearch());

This gets compiled out and never gets called.

searchButton.addEventListener("click", e-> {doSearch();return true;});

This works using the AddEventListenerListenerCallback function.

I've tried compiling with and without the -generateJsInteropExports flag and get the same result. I was using an earlier GWT snapshot version (end of June) until a few days ago and didn't get the problem with that version.

Any ideas or is this a bug?
Thanks
Steve

Steve Andrews

unread,
Jul 22, 2016, 3:08:57 AM7/22/16
to GWT Contributors
I've now got this to work. I cleaned my SDM cache :-) 

It only works with the generateJsInteropExports flag set though.

Jakob Jarosch

unread,
Jul 22, 2016, 5:50:22 AM7/22/16
to GWT Contributors
I made similar experiences, in GWT 2.8 the SDM cache is sometimes corrupt and even a restart of SDM won't bring it back alive. Only solution I found was cleaning temporary files.
In GWT 2.7 there was sometimes the need to restart SDM, but never the need to clean the temporary files.

Jens

unread,
Jul 22, 2016, 6:31:24 AM7/22/16
to GWT Contributors

It only works with the generateJsInteropExports flag set though.

Sounds like a bug to me.

-- J.

Steve Andrews

unread,
Jul 28, 2016, 3:27:35 AM7/28/16
to GWT Contributors
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.

I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.

I've also found that Window.location returns an Object - will this be sorted in a future release?

Other than that Elemental is working well so far! Nice work!

Steve

Goktug Gokdogan

unread,
Aug 1, 2016, 3:48:13 PM8/1/16
to google-web-toolkit-contributors
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/16498b97-7d3d-44c7-b42b-e40be9de1e26%40googlegroups.com.

Steve Andrews

unread,
Aug 2, 2016, 4:51:38 AM8/2/16
to GWT Contributors
I've created a quick test project and put it at https://github.com/steveandrews01/JsInteropTest

The click listener only works if compiled with the flag set. If I run it without the flag and inspect the DOM in Chrome then the event listener is not attached to the button.

(Changing the flag needs a SDM cache clear!)

Steve


On Monday, 1 August 2016 20:48:13 UTC+1, Goktug Gokdogan wrote:
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.

I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.

I've also found that Window.location returns an Object - will this be sorted in a future release?

Other than that Elemental is working well so far! Nice work!

Steve

On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:

It only works with the generateJsInteropExports flag set though.

Sounds like a bug to me.

-- 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+unsubscribe@googlegroups.com.

Roberto Lublinerman

unread,
Aug 2, 2016, 3:10:12 PM8/2/16
to google-web-tool...@googlegroups.com
Looking at the elemental code that uses a lambda which will not be EventHandler but a JsFunction. Could you try with an anonymous EventHandler instead?

On Tue, Aug 2, 2016 at 1:51 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've created a quick test project and put it at https://github.com/steveandrews01/JsInteropTest

The click listener only works if compiled with the flag set. If I run it without the flag and inspect the DOM in Chrome then the event listener is not attached to the button.

(Changing the flag needs a SDM cache clear!)

Steve


On Monday, 1 August 2016 20:48:13 UTC+1, Goktug Gokdogan wrote:
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.

I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.

I've also found that Window.location returns an Object - will this be sorted in a future release?

Other than that Elemental is working well so far! Nice work!

Steve

On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:

It only works with the generateJsInteropExports flag set though.

Sounds like a bug to me.

-- 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-co...@googlegroups.com.

--
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-co...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fca60fc6-7cfd-44ea-9728-295c77293d74%40googlegroups.com.

Steve Andrews

unread,
Aug 3, 2016, 3:05:38 AM8/3/16
to GWT Contributors
I've done some more tests with an anonymous handler and also a dynamically created button in case it was a UiBinder problem. None of the click handlers are working without the exports flag set.


Steve


On Tuesday, 2 August 2016 20:10:12 UTC+1, Roberto Lublinerman wrote:
Looking at the elemental code that uses a lambda which will not be EventHandler but a JsFunction. Could you try with an anonymous EventHandler instead?
On Tue, Aug 2, 2016 at 1:51 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've created a quick test project and put it at https://github.com/steveandrews01/JsInteropTest

The click listener only works if compiled with the flag set. If I run it without the flag and inspect the DOM in Chrome then the event listener is not attached to the button.

(Changing the flag needs a SDM cache clear!)

Steve


On Monday, 1 August 2016 20:48:13 UTC+1, Goktug Gokdogan wrote:
Can you share a small repro for this? (EventListener requiring generateJsInteropExports)
On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews <stevean...@gmail.com> wrote:
I've done some more testing and cleared my cache and can still only get EventListener to work with the generateJsInteropExports flag set.

I've had another problem with EventListener on a select element but I'm using an external framework for my project (Materialize) and think that it's their framework that doesn't like the EventListener object. If I use a standard select element then it's working. I can get around this by adding the listener through a JQuery wrapper so no problem.

I've also found that Window.location returns an Object - will this be sorted in a future release?

Other than that Elemental is working well so far! Nice work!

Steve

On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:

It only works with the generateJsInteropExports flag set though.

Sounds like a bug to me.

-- 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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

stuckagain

unread,
Aug 8, 2016, 9:27:49 AM8/8/16
to GWT Contributors

In case of EventHandlers it blocks me from using a lambda in addEventListener. The GWT compilers gives an error that the method is ambiguous. While eclipse or the javac does not seem to have a problem with it.

stuckagain

unread,
Aug 8, 2016, 9:40:26 AM8/8/16
to GWT Contributors
Some comments:

- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?

Goktug Gokdogan

unread,
Aug 8, 2016, 8:11:03 PM8/8/16
to google-web-toolkit-contributors
On Mon, Aug 8, 2016 at 6:40 AM, stuckagain <david...@gmail.com> wrote:
Some comments:

- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.

Yes, we will look into.
 
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?


We can probably make it final but if we know it is readonly but I think we are not sure when the field is readonly. Julien?
 
--
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+unsubscribe@googlegroups.com.

Julien Dramaix

unread,
Aug 9, 2016, 6:44:47 AM8/9/16
to google-web-toolkit-contributors
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?


> We can probably make it final but if we know it is readonly but I think we are not sure when the field is readonly. Julien?

a property flagged as @Const could be make final if it belongs to a class or convert to a simple getter if it belongs to an interface.

That being said, clutz doesn't convert correctly a constant closure property to a constant typescript property.

I've created a bug internally to track this problem.

On Tue, Aug 9, 2016 at 2:11 AM 'Goktug Gokdogan' via GWT Contributors <google-web-tool...@googlegroups.com> wrote:
On Mon, Aug 8, 2016 at 6:40 AM, stuckagain <david...@gmail.com> wrote:
Some comments:

- Is there a possibility that the API's don't overuse double in the future ? For example the XMLHttpRequest.status property is supposed to be an integer not a double.

Yes, we will look into.
 
- The API's do not use set/get/is as was the case in the old Elemental. So how can I now detect that a property is readOnly ?


We can probably make it final but if we know it is readonly but I think we are not sure when the field is readonly. Julien?
--
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-co...@googlegroups.com.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA22pvB4kqUCF9figh9FHTdEHk_nB39wqx7_EFng3VKicQ%40mail.gmail.com.

Luke Last

unread,
Aug 11, 2016, 11:48:16 PM8/11/16
to GWT Contributors
What's the best way to type cast objects? I get a ClassCastException in super dev mode with the following.

ArrayBuffer ab = (ArrayBuffer) fileReader.result;

The exception stems from com.google.gwt.lang.Cast#castToNative

If I use JSNI to perform the cast it works fine.

Thanks for working on Elemental2. I think it's super important for GWT.
-Luke

James Horsley

unread,
Aug 19, 2016, 10:11:58 AM8/19/16
to GWT Contributors
I remember hearing that elemental2 was being generated from TypeScript definitions. If that's true, is there any chance we could get a look at the generator code too?

Julien Dramaix

unread,
Aug 19, 2016, 11:27:43 AM8/19/16
to GWT Contributors
elemental2 is generated from closure extern files. 

The open source version of the generator should have a support for converting d.ts file to java. We don't know yet when the generator will be open sourced.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com.

James Horsley

unread,
Aug 19, 2016, 11:57:45 AM8/19/16
to GWT Contributors
Sounds great. Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com.

Ray Cromwell

unread,
Aug 19, 2016, 11:58:44 AM8/19/16
to google-web-toolkit-contributors
Is the underlying object actually an ArrayBuffer? The return value is
supposed to be either an ArrayBuffer or a String depending on how you
invoke the reader API.

It seems to me that any methods which might throw CCE because of this
should actually return null, e.g.


class FileReader {

public @JsOverlay ArrayBuffer getArrayBufferResult() {
Object result = getResult();
return result instanceof ArrayBuffer ? (ArrayBuffer) result : null;
}

public native Object getResult();
> --
> 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-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e0b5ae3d-e987-40e4-9d70-dfde08f1ffc2%40googlegroups.com.

Gilberto Torrezan Filho

unread,
Aug 23, 2016, 2:57:00 PM8/23/16
to GWT Contributors
Hi Julien,

This generator will take GWT to the next level. Integrating GWT with existing js libraries was always time-consuming and error-prone (using either JNSI or jinterop).

What is the status of it (what is holding back the project from being open-sourced)? Can we help in any way?

Marcio Alves

unread,
Nov 25, 2016, 9:08:07 PM11/25/16
to GWT Contributors
Hi, 

    It looks like there are some classes from elemental2 that can't be extended. For instance HTMLElement.

    When I try to extend the class and create the new class the navigator throw an error:

   " Failed to construct 'HTMLElement': Please use the 'new' operator, this DOM object constructor cannot be called as a function "

   Any ideas on how to solve this error?

Thanks!

Goktug Gokdogan

unread,
Nov 28, 2016, 11:45:11 AM11/28/16
to google-web-toolkit-contributors
I'm assuming you are trying define a custom element.
I don't believe such elements are constructable by 'new' operator in many browsers (yet).

--
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+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7100c19d-2372-4461-8efc-3ccf2c513116%40googlegroups.com.

Marcio Alves

unread,
Nov 29, 2016, 10:28:17 AM11/29/16
to GWT Contributors
Thanks for the hint!

I'm using vaadin elements that expose then as interfaces.

Hua Zhang

unread,
Dec 16, 2016, 5:21:42 AM12/16/16
to GWT Contributors
A new experimental version of Elemental2 using the new JsInterop specification has been pushed on Sonatype today.

I just tested websocket functionality of Elemental2, it works very fine for me.

I am curious if there is any functionality difference between Elemental1 and 2?

When can I expect a stable release of Elemental2?

John Huss

unread,
Feb 2, 2017, 4:04:05 PM2/2/17
to GWT Contributors
I tried this out by converting a small project that was using elemental 1 to elemental 2.  I was able to get it to compile both in dev mode and in a production compile.  But my event listeners weren't firing at all when I ran it.

Some feedback:

1) Lambda event listeners have to be cast into order to avoid an error from "javac": 

    [javac] /Users/john/.../src/com/App.java:208: error: reference to addEventListener is ambiguous

    [javac] doc.getElementById("list").addEventListener("click", event -> listPressed(event));

    [javac]                                ^

    [javac]   both method addEventListener(String,AddEventListenerListenerCallback) in Node and method addEventListener(String,EventListener) in Node match


You can avoid this error with an explicit cast to EventListener (or AddEventListenerListenerCallback), but that isn't ideal:

    .addEventListener("click", (EventListener)event -> listPressed(event));


2) Some things weren't defined on HTMLElement that I needed, namely: "outerHTML" and "children". These were available in elemental 1. They can be added by extending the class like so and casting to it:

    @JsType(isNative = true, namespace = JsPackage.GLOBAL)

    public class HTMLElementEx extends HTMLElement {

         public String outerHTML;

    public HTMLCollection<HTMLElement> children;

    }



On Wednesday, June 29, 2016 at 7:23:51 PM UTC-5, Julien Dramaix wrote:

A new experimental version of Elemental2 using the new JsInterop specification has been pushed on Sonatype today.


David

unread,
Feb 3, 2017, 4:38:37 AM2/3/17
to GWT Contributors
I had the same issue that the EventListeners were not triggered.
It was solved by adding -generateJsInteropExports to the SDM startup and to the gwtc arguments.

Make sure that you delete the folder in temp that is generated by SDM. In my case, for unknown reason to me, adding the flag did not clear the cache.


--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cb6c43-cd40-494d-88eb-2aa786a18b6a%40googlegroups.com.

Ming-Yee Iu

unread,
Feb 11, 2017, 6:11:20 PM2/11/17
to GWT Contributors
It's a little unfortunate that Elemental is being developed privately since it's the one part of GWT that's self-contained enough that I am able and willing to contribute to it. But is it possible to get an early, unofficial, unsupported code drop of the current Elemental code generator?

I'm a big user of Elemental 1, and I'm thinking about custom generating my own framework instead of using Elemental 2 so that I can have an API that works better with my own workflow. Being able to see the existing code generator would help me in knowing how much work would be involved and would allow me to avoid duplicating effort. 

If that's not possible, would it be possible to at least get some details about the implementation? Is it written in Python like Elemental 1 was or is it written in Java? What data sources does it consume? Does it take Typescript or Web IDL as input or something else?

Thanks
-Ming

Jens

unread,
Feb 12, 2017, 8:37:21 AM2/12/17
to GWT Contributors

What data sources does it consume? Does it take Typescript or Web IDL as input or something else?

According to a GWTcon 2016 Video the generator uses Closure extern files as well as TypeScript definition files so you can use it to generate JsInterop wrappers for lots of JS libraries.

-- J.

CodeLess

unread,
Feb 12, 2017, 9:10:48 AM2/12/17
to google-web-tool...@googlegroups.com
Link to this video please?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/eec8a65f-991d-4b88-9dcf-ad6956beb060%40googlegroups.com.

Thomas Broyer

unread,
Feb 12, 2017, 9:40:35 AM2/12/17
to GWT Contributors

Predrag Remark

unread,
Feb 12, 2017, 4:06:14 PM2/12/17
to GWT Contributors
Thank you Thomas.

Goktug Gokdogan

unread,
Feb 13, 2017, 5:42:28 PM2/13/17
to google-web-toolkit-contributors, Julien Dramaix
+dramaix

On Sat, Feb 11, 2017 at 3:11 PM, Ming-Yee Iu <ji...@jinq.org> wrote:
It's a little unfortunate that Elemental is being developed privately since it's the one part of GWT that's self-contained enough that I am able and willing to contribute to it. But is it possible to get an early, unofficial, unsupported code drop of the current Elemental code generator?


 
I'm a big user of Elemental 1, and I'm thinking about custom generating my own framework instead of using Elemental 2 so that I can have an API that works better with my own workflow. Being able to see the existing code generator would help me in knowing how much work would be involved and would allow me to avoid duplicating effort. 

Writing a generic generator is complex task since Closure and TypeScript type system are quite rich. Our generator is already over 25k and growing. It might be more trivial if you just target a subset and gave up strictness of the types in the API (e.g. using Object when you see union types).
 

If that's not possible, would it be possible to at least get some details about the implementation? Is it written in Python like Elemental 1 was or is it written in Java? What data sources does it consume? Does it take Typescript or Web IDL as input or something else?

It is written in Java and supports 2 entry points:
  1- TypeScript input which uses official TypeScript parser/AST. 
  2- Closure extern files which uses Closure compiler / AST.

Both entry points end up creating a common Java model that rest of the generation pipeline runs over and finalizes the Java APIs.
 

Thanks
-Ming

--
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+unsubscribe@googlegroups.com.

Ming-Yee Iu

unread,
Feb 15, 2017, 4:05:01 PM2/15/17
to GWT Contributors, dra...@google.com
Well, ok. Thanks.

Just in terms of general feedback on Elemental2:

1. I'm not sure whether the conversion of JavaScript properties to Java fields is the best choice. Sure, it "feels" more like the original JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid that a Java compiler might apply some unexpected optimization there as a result, c) it's harder to mock the behavior of the classes for unit tests and d) alternate implementations of Elemental2 aren't possible (for example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I did with Elemental 1).

2. Personally, I would prefer if Elemental 2 used interfaces over classes (for similar reason as above), though I understand that being able to use "new ...()" syntax on things is nice too.

3. The number of callback classes is out-of-control. Can they be consolidated somehow? 

4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.

5. Can there be some magic that makes elemental2.Iterable<T> a real Java Iterable?

Otherwise, it seems nice. I like that there's a NodeList<T> now!

John Huss

unread,
Feb 15, 2017, 4:15:07 PM2/15/17
to GWT Contributors, dra...@google.com
I agree about preferring "bean" style properties.  It's not a clear choice, but using bean style properties is more familiar to java programmers and makes the library fit in much better with the wider java ecosystem.  Also it would make conversions from elemental 1 much easier (though that is probably a very small group of users).

Goktug Gokdogan

unread,
Feb 15, 2017, 5:01:01 PM2/15/17
to google-web-toolkit-contributors, Julien Dramaix
Thanks for the feedback.

On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu <ji...@jinq.org> wrote:
Well, ok. Thanks.

Just in terms of general feedback on Elemental2:

1. I'm not sure whether the conversion of JavaScript properties to Java fields is the best choice. Sure, it "feels" more like the original JavaScript, but
 
a) it's inconsistent with Java semantics,

This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style.
 
b) I'd be afraid that a Java compiler might apply some unexpected optimization there as a result,

I don't think that's possible.
 
 c) it's harder to mock the behavior of the classes for unit tests

Actually a field doesn't require mocking; but native accessor as you are proposing does require mocking.
 
and d) alternate implementations of Elemental2 aren't possible (for example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I did with Elemental 1). 

I can see how accessor can help with this as it gives you more flexibility on your  re-implementation of the API.
 

2. Personally, I would prefer if Elemental 2 used interfaces over classes (for similar reason as above), though I understand that being able to use "new ...()" syntax on things is nice too.

 

3. The number of callback classes is out-of-control. Can they be consolidated somehow? 


Hopefully next release will cleanup plenty of them.
 
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.

The language gap between TypeScript and Java is actually higher than Closure and Java. That makes it harder to precisely mimic type info that exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.
 

5. Can there be some magic that makes elemental2.Iterable<T> a real Java Iterable?

We can probably do something here. Will track that issue.
 

Otherwise, it seems nice. I like that there's a NodeList<T> now!

--
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+unsu...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cb2a997b-2d25-43c0-911a-ba13a448e14e%40googlegroups.com.

Ming-Yee Iu

unread,
Feb 15, 2017, 6:33:57 PM2/15/17
to GWT Contributors, dra...@google.com
a) it's inconsistent with Java semantics,

This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style. 

I guess I'm referring to how field access in Java are simply variable modifications whereas property accesses in JavaScript can trigger additional behaviors. In normal Java code, something like 

   canvas.width = 50

is pretty inert. But in Elemental, that code automatically triggers a resizing and relayout of the element. Or perhaps a better example is innerHTML. Or even something like

   el.scrollTop = -5;
   System.out.println(el.scrollTop);   // prints out 0, which this is impossible in real Java

I'm not sure whether these would be described as semantic or stylistic differences. But they're unexpected.


 c) it's harder to mock the behavior of the classes for unit tests

Actually a field doesn't require mocking; but native accessor as you are proposing does require mocking.

Well, it sort of depends. Since JavaScript properties actually trigger additional behaviors, I might want to mock the properties to ensure these behaviors are being triggered correctly. I might want to mock innerHTML to ensure that the correct UI is being set-up and then use that trigger some additional mocking. (Or is this not mocking? I'm unclear on the correct test terminology for that.) I suppose that things can be worked around by just testing field values. And I'm not sure if people actually unit test user interfaces like that. It's just a trade-off, I suppose.
 
 
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.

The language gap between TypeScript and Java is actually higher than Closure and Java. That makes it harder to precisely mimic type info that exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.
 

Sure. I was just thinking that it would be nice if the code generator could suck in additional data from other sources to supplement the info it can use to generate interfaces. The hand-built types in TypeScript is a good information source for event handlers. And Web IDL has good information on whether numbers are integers or floats. I'm just throwing it out there as possible future improvements.

Colin Alworth

unread,
Feb 15, 2017, 6:34:08 PM2/15/17
to GWT Contributors, dra...@google.com


On Wednesday, February 15, 2017 at 4:01:01 PM UTC-6, Goktug Gokdogan wrote:
Thanks for the feedback.

On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu <ji...@jinq.org> wrote:
Well, ok. Thanks.

Just in terms of general feedback on Elemental2:

1. I'm not sure whether the conversion of JavaScript properties to Java fields is the best choice. Sure, it "feels" more like the original JavaScript, but
 
a) it's inconsistent with Java semantics,

This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style.
 
There are also a variety of tools that assume methods rather than fields - uibinder, cssresource, editors all made assumptions about turning dot notation into getters (and in the case of editors, setters), and did not support fields at all as far as I'm aware. This is true of most (though not all) codegen tools I've worked with since as well.

Another advantage: You can't turn a field into a method-reference.
 

Julien Dramaix

unread,
Feb 15, 2017, 6:59:10 PM2/15/17
to Colin Alworth, GWT Contributors
The problem with generating getters and setters is that you can potentially conflict with an existing method. I had this problem when I've generated the java classes to interacting with the typescript compiler. Some classes had a field named foo and a method named getFoo() and that's not necessarily a simple getter.
--

Julien Dramaix | Software Engineer | dra...@google.com | 650-750-6053

Goktug Gokdogan

unread,
Feb 15, 2017, 7:19:03 PM2/15/17
to google-web-toolkit-contributors, Julien Dramaix
On Wed, Feb 15, 2017 at 3:33 PM, Ming-Yee Iu <ji...@jinq.org> wrote:
a) it's inconsistent with Java semantics,

This could be a stylistic inconsistency not a semantic one. All arguments that I have seen in favor for having accessors instead of fields are inapplicable to Elemental fields since they all assume changes in the implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we might end up providing setter/getter as overlays for people who would like to stick conventional style. 

I guess I'm referring to how field access in Java are simply variable modifications whereas property accesses in JavaScript can trigger additional behaviors. In normal Java code, something like 

   canvas.width = 50

is pretty inert. But in Elemental, that code automatically triggers a resizing and relayout of the element. Or perhaps a better example is innerHTML. Or even something like

   el.scrollTop = -5;
   System.out.println(el.scrollTop);   // prints out 0, which this is impossible in real Java

I'm not sure whether these would be described as semantic or stylistic differences. But they're unexpected.

I don't consider this strictly related accessor vs. field. Javascript interoperation in general could have such unexpected behavior and it is surprising in both scenarios. A developer should always be aware Elemental is actually calling into browser.
 


 c) it's harder to mock the behavior of the classes for unit tests

Actually a field doesn't require mocking; but native accessor as you are proposing does require mocking.

Well, it sort of depends. Since JavaScript properties actually trigger additional behaviors, I might want to mock the properties to ensure these behaviors are being triggered correctly. I might want to mock innerHTML to ensure that the correct UI is being set-up and then use that trigger some additional mocking. (Or is this not mocking? I'm unclear on the correct test terminology for that.) I suppose that things can be worked around by just testing field values. And I'm not sure if people actually unit test user interfaces like that. It's just a trade-off, I suppose.

If your test depends on additional behavior that would be normally triggered by setting innerHtml, I think at that point you should not test that code by mocking elemental. (Actually in general most code that relies on elemental better be tested without mocking - it is much better to test with actual browser behavior.)
 
 
 
4. Also, is it possible to supplement the typing information for some of those callbacks from Typescript? Everyone knows that "onclick" handlers pass a MouseEvent. I'm not sure if Closure has a rich enough type system or is sufficiently well-developed to generate the best API there.

The language gap between TypeScript and Java is actually higher than Closure and Java. That makes it harder to precisely mimic type info that exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.
 

Sure. I was just thinking that it would be nice if the code generator could suck in additional data from other sources to supplement the info it can use to generate interfaces. The hand-built types in TypeScript is a good information source for event handlers. And Web IDL has good information on whether numbers are integers or floats. I'm just throwing it out there as possible future improvements.

--
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+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/827ac42b-638f-49f4-b67b-0f3675808879%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages