Monday, June 13, 2016

Re: JsInterop and Java collections?

On Tuesday, June 7, 2016 at 12:58:53 AM UTC+2, Thomas Broyer wrote:

On Monday, June 6, 2016 at 9:15:43 PM UTC+2, Hristo Stoyanov wrote:
I did not suggest to *convert*, but *map*. That means that if/when a JSInter-oped class is exported into the JS Engine (let's say V8) , the JS developer will see plain old js arrays, so s/he can work with them as they have been for ages. When Java/JsInterop developers work with the same structure, they can chose to view it as java.util.ArrayList, java array or some other java.util.Collection, thus using familiar Java APIs. It is the same structure in the JS Engine memory, but viewed differently. But no conversion involved.

Some of those might work, but not all.
I.e. "seeing" a JS Array as a java.util.List might work, but not the reverse; at least not with any java.util.List, only the one implementing type(s) that directly map (@JsType(isNative=true)) to a JS Array. More precisely, that means using that specific JsType on setting (and on getting, though possibly JsInterop could special-case it; I think that's what you're asking for); specifically, a setter taking any java.util.List wouldn't work, as you could pass, say, a LinkedList, and GWT would be unable to simply "map" it to a JS Array: we're compiling to JS here, there's no boundary like with a plugin.
Currently, you could use elemental.util.ArrayOf, and I believe there will be equivalents in due time (either GWT 2.8 proper, or Elemental 2). This is more or less what Jens and Vassilis were talking about already.


You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment