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: >> >> Kirrill, >> 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. >
FWIW: https://github.com/gwtproject/gwt/issues/9364 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
