Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

[Goktug Gokdogan (Google Drive)]

I've shared an item with you.

This is a design doc that describes a proposal for improving interoperability with GWT and javascript. The proposal provides some essential pieces to provide better and easier interoperability with JS while putting more complex scenarios (e.g. Web Components) and testability into account.

Please take a look and provide us some feedback.

Cheers,

 - Goktug

Nextgen GWT/JS Interop (Public)

Google Drive: create, share, and keep all your stuff in one place.

[Xavier Mehaut]

Hi goktuk

A nice way to interop with js is the way typescript does through the .d.ts files where js api is declared in a typed way, ensuring then the ability to interop with any preexisted js. Moreover, already existing .d.ts files for many js libraries exist on 
https://github.com/borisyankov/DefinitelyTyped

No extra wirk to do then :)

Best regards

Xavier

Envoyé de mon iPhone

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Colin Alworth]

Nice writeup. Comments/questions (since comments seem disabled in the docs):

 * @Entry looks great - there has been some discussion in IRC about some way to do this for easier library wrapping code, but every direction we looked at with JSOs ended up with a little more cruft than we really wanted to see. Maybe worth mentioning that $entry doesn't just do exceptions, but also makes scheduleFinally behave as expected.
 * Constructors - how is one supposed to new up an object that implements a specific interface without making your own implementation (and thus declaring new implementations)? Are we keeping the static-method-only restriction, or can we use new? Similarly, how will these objects pass through the java/js barrier - are they to be a special class of objects in JSNI, allowed to be manipulated in plain JS instead of opaque objects, but still able to be instanceof'd?
 * Java 8 support/requirement - currently the GWT release jars are compiled to target java 6 (according to common.ant.xml), so that they can be used in a project that supports either 6 *or* 7 (and of course newer). If this new code is used at all internally with java8-only features, does this mean that support will be *dropped* for both 6 and 7 instead of merely *adding* java 8 support?
 * (JSNI doc) primitives - why support for long, which JS VMs don't actually support, but not float/short/byte?
 * (JSNI doc) forEach - will there be a function/callback interface that will be autowrapped in $entry and bind to be passed in, or will this simply access a JSO that will be treated as a function?

[Goktug Gokdogan]

We were planning to look into making integration seamless if closure type annotations exists but that's kind of orthogonal to this proposal.

When we have that integration, it might not be hard to utilize typescript via typescript to closure conversion.

Thanks for suggestion.

[Goktug Gokdogan]

Thanks for the feedback.

My response are inline:

On Tue, Aug 6, 2013 at 10:33 AM, Colin Alworth <nilo...@gmail.com> wrote:

Nice writeup. Comments/questions (since comments seem disabled in the docs):

 * @Entry looks great - there has been some discussion in IRC about some way to do this for easier library wrapping code, but every direction we looked at with JSOs ended up with a little more cruft than we really wanted to see. Maybe worth mentioning that $entry doesn't just do exceptions, but also makes scheduleFinally behave as expected.

Will update the doc.

 

 * Constructors - how is one supposed to new up an object that implements a specific interface without making your own implementation (and thus declaring new implementations)? Are we keeping the static-method-only restriction, or can we use new?

We are not planning a static-method-only restriction. However as these classes are interfaces, you cannot just call constructor and that makes sense because it is just an "interface contract" and we don't really know how to really instantiate.

However, if the prototype attribute is set on @JsInterface, then it is no longer only an interface contract; now it also represents a real js object with a known constructor. In that case you can instantiate it with the generated .Prototype class or Js.Object.create:

e.g.

  button = new Button.Prototype("Click");

or 

  button = Js.Object.create(Button.class); // subject to change

 

Similarly, how will these objects pass through the java/js barrier - are they to be a special class of objects in JSNI, allowed to be manipulated in plain JS instead of opaque objects, but still able to be instanceof'd?

Interface annotated with @JsInterface is special treated with compiler; and guarantees the contract of a JS or Java object with disabling optimizations, obfuscation and rely on prototype dispatch. That means they will be real js objects unlike of the older JSOs.

 

 * Java 8 support/requirement - currently the GWT release jars are compiled to target java 6 (according to common.ant.xml), so that they can be used in a project that supports either 6 *or* 7 (and of course newer). If this new code is used at all internally with java8-only features, does this mean that support will be *dropped* for both 6 and 7 instead of merely *adding* java 8 support?

I designed based on Java 8 and have a hard dependency on "default" methods. But the solution should might need to work with 7 for a while if we can't drop it by GWT 3.0. To achieve that I think we can do a pre-processing and do some code generation for default methods (though not sure about the details yet).

 

 * (JSNI doc) primitives - why support for long, which JS VMs don't actually support, but not float/short/byte?

I only included long because as far as I know that is the only one that we do emulation and changes some behavior.

But on the other hand it matter the least because we can't avoid autoboxing. I'll drop that.

For the rest, int and double covers all autoboxing related issues so the developer can just do a primitive cast.

 

 * (JSNI doc) forEach - will there be a function/callback interface that will be autowrapped in $entry and bind to be passed in, or will this simply access a JSO that will be treated as a function?

If you are asking specific to Js.Array.foreach;

It doesn't need to be a JSO; you can pass a lambda expression. it will not be wrapped with $entry (as it is a synchronous call and not actually an entry point to the app).

 

On Tuesday, August 6, 2013 2:24:47 AM UTC-5, Goktug Gokdogan wrote:

I've shared an item with you.

This is a design doc that describes a proposal for improving interoperability with GWT and javascript. The proposal provides some essential pieces to provide better and easier interoperability with JS while putting more complex scenarios (e.g. Web Components) and testability into account.

Please take a look and provide us some feedback.

Cheers,

 - Goktug

Nextgen GWT/JS Interop (Public)

Google Drive: create, share, and keep all your stuff in one place.

--

[Goktug Gokdogan]

Jon (Stalcup) just warned me that it may not necessarily orthogonal so I will make a clarification to what I said.

There are number of reasons why it makes we sense to define the contract with java syntax and interface files for GWT (easy IDE support and JDT integration and developer familiarity etc.), but someone might have chosen to start with a custom syntax like the d.ts files.

Assuming these interfaces exist and understood by the compiler, any other support can be built on top of that by generating them and provide a seamless integration.

[Brian Slesinsky]

It might be nice to be able to say that anything defined in a .d.ts can be imported into GWT. This will make it easier to work with JavaScript programmers since they don't have to write any Java code. So perhaps it's worth making sure that generating the Java interfaces from .d.ts files will work? I know that generating Elemental code from WebKit IDL files wasn't easy.

However, our main use case is to import web components which are new. So my question is how likely people are to write .d.ts files for web components; I don't know if there is much overlap between those two communities yet.

[Xavier M.]

Yep, insuring a clear interface between different world is always valuable and even mandatory in my opinion.. Typescript .d.ts files have already made the job, so why not using this syntax. As a early adopter of gwt in 2006, i could also say that I'm an early adopter of typescript on real projects (not Dart I 'don't like), an Typescript convinced me... GWT has several abilities Typescript have not yet and making a bridge between the two approaches would be very nice. In my sense, the future if Ecmascript6 and later... GWT with java8 could be a pragmatical competitor.

regards

Xavier

2013/8/8 Brian Slesinsky <skyb...@google.com>

--
Bien cordialement,
Xavier

[Ray Cromwell]

As cool as I think TS is, there are far more lines of code out there in Js, some even with JsDoc type assertions, so I think the latter would be more useful as a first pass. JsDoc is comments so it works with existing JS. We could explore importing libraries defined in TS, Dart, haXe, et al via some kind of standard plugin extension.

[Xavier Mehaut]

I desagree with this assertion ; the goal is not to interop with ts, haxe, coffee, ..., but only with js. Moreover the future of js is ecmascript 6, so ts is a good candidate to express properly an interface; this is not the case IMO of a jsdoc like solution which is verbose and not so precise and concise as a true language.

To finish, i recall in mind 
https://github.com/borisyankov/DefinitelyTyped

as a reminder of the power of the d.ts technics

Best regards

Xavier

Envoyé de mon iPhone

[Brian Slesinsky]

I think that's a good point; someone went through the trouble of creating these definition files so it would be nice to be able to use them, even without using TypeScript at all. (On the other hand, how many of those libraries would you say are relevant for GWT? I don't see us using backbone.)

For Google, we would want a way to generate Java interfaces from JsDoc type declarations because that's what we use. Also, there may be legal issues using parts of TypeScript without the whole thing so someone would have to investigate that.

[Goktug Gokdogan]

First of all, as long d.ts works, end user should not care if the compiler directly understands it or there is a converter in between.

Even the starting point is d.ts or type annotations, in order to have good IDE support you still need a java representation so that your code will compile and auto complete.

With java syntax, there are no special syntax coloring support required by IDE and you have the refactoring support.

Also my expectation is; regular java interfaces should require minimal customization and special treatment in JDT and AST, compared to anything else.

Interfaces also work well in jre only environment and jre unit tests.

On top of all of these, GWT target user group is java developers who already familiar with java interfaces and they don't need to learn something new.

However, given that corresponding js has type information (via jsdoc or d.ts), we can make the process seamless and not require manual interface creation. 

Generating elemental from Webkit IDL was difficult mostly because of the limitations of expressibility via JSOs; so I'm not worried much.

There is already a d.ts to closure converter so if we support interface generation from closure than 'theoretically' d.ts support will be free.

[Ray Cromwell]

AFAIK, JsDoc actually is more expressive than TypeScript, for example, TS doesn't currently support union types IIRC, which is critical for expressing real world Javascript libraries. It is also a form of repeating yourself to specify a TS file, because a Javascript programmer writing his library code is not going to document it in two places by creating separate files for everything. That repo is great for TS programmers, but honestly, I don't imagine a high velocity JS project constantly keeping these bindings in sync. Who is going to be responsible for updating the TS interface definitions everytime a release of the underlying JS library is pushed?

We've had the same problem with GWT JSNI wrappers in the past, they get out of sync with the JS library that are mapping to, because the person maintaining the JS library doesn't care. 

I don't have anything against TS, I'm all for first class typing, but I think a solution in which the person who maintains the JS library themselves is encouraged to add the types is superior, and I don't have a high degree of confidence that JS developers enmasse are going to adopt writing TS definitions. Also, I haven't been following ES6 recently, but as far as I'm aware, there are no plans to add either optional types of documentary types. 

The way I'd propose building this is just to have a pluggable parser for collecting the type definitions, and so when the compiler sees a given .js input file, it asks the plugins to hand back all of the first class type definitions for that file. The format could be anything, parsing JsDoc, loading TS, WebIDL, or XML files like IntelliJ uses. The JS world is too fragmented probably to have one solution.

However I will say this: We are looking at replacing the backend JsAst of the GWT compiler with Closure Compiler in the future, so that we don't need to maintain the JS optimization pipeline (only the Java optimization stages), and so using Closure types as intermediate representation makes a lot of sense.

 

On Thu, Aug 8, 2013 at 2:25 PM, Xavier Mehaut <xavier...@gmail.com> wrote:

[Jörg Hohwiller]

Hi Goktug,

nice approach. IMHO getters and setters should not be required to be annotated by @JsProperty. Instead a method looking like a getter or setter that is actually not a property accessor should be annotated (Convention over configuration).
I would love to see this coming...

Cheers
  Jörg

[Goktug Gokdogan]

Interesting idea; though we still need an annotation when the name is not a valid java identifier and also can't find a good name to mark the exception case.

Another issue is anyone who is not aware of convention can be surprised by it (e.g. developer renames a method and the method is no longer a js function).

Do you aware of any popular java lib that solves a similar problem by conventions so that I can take a look for ideas?

--

[Joseph Gardi]

I have a few questions about exporting:

It said: "@JsExport can only be applied to constructors, static fields and static methods, and whole concrete classes.
".  Does this mean that we'll just continue to use GWT-exporter for this or will there be another way. Also, what will be the easiest way to export the API's of entire libraries? I had this need but decided it was too difficult so I just used a javaScript library instead. 

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

[Goktug Gokdogan]

@JsExport exports constructors and static members and pins them so they act as entry points and not get pruned.

On the other hand, @JsType enforces generation of javascript compatible prototype for the class so if there is a method named "someMethod" in the Java object, same method with same name exists in javascript object.

So if you are coming from GWT-Exporter, you can have the same behavior by adding both JsExport and JsType to the same class that you want to use in javascript land (this part may change before we release the first phase of JsInterop - it is little bit confusing)

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/e19b5c6d-cbe0-4993-962b-ca01c3eb6d7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph Gardi]

that makes sense. How would I apply the @JsExport and @JsType to a third party library without forking it though?

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/TlFmmJfH7Pk/unsubscribe.
To unsubscribe from this group and all its topics, 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%3DyUA1fWZQQevrPEx1dXkpCJNLJXMAKn7-0ouDJdA2SG1zHNA%40mail.gmail.com.

[Goktug Gokdogan]

We are going to introduce configuration file based exports in the future however for now your best bet is to super-source the files and add annotations that you need.

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

[Joseph Gardi]

thanks. Sounds exciting.

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