Paul,
Yes, it boils down to JSInterop automatically handling some well-known
implementations of java.util.List (LinkedList,ArrayList) as JS arrays. The
direction Java->JS is easy: the JsInterop will map anything implementing
java.util.List into js array. JS developers only see arrays on the other
side, have no idea what the Java developer used. For the opposite
direction, if the targeted member is non-standard or ambiguous, a helper
converter annotation might be needed, for example:
This may need a helper converter:
@JsType(isNative = true ...)
> public class Foo {
> ...
> @JsPropery(useListMapper=com.my.SpecialListConvertor.class)
> public List<WhateverJSType> myAmbiguousList;
> }
but this should need no helper:
>
>
> @JsType(isNative = true ...)
> public class Foo {
> ...
> @JsPropery
> public ArrayList<WhateverJSType>
> myWellKnownListThatJsInteropKnowHowToHandleAlready;
> }
Essentially, this is a converter similar to what Jen put in his example,
but made available to JsInterop during code generation.
I still think this approach would be superior that the umbrella interface
like your (for example gwt.interop.utils.shared.collections.Array) for 2
reasons:
1. Less code, simpler
Creating instances does not need to be done with dependency injection
engine (or worse - global singleton constructor factories, like you did
with your latest update. Think carefully about all the cruft this adds!)
2. Java developers are not forced to deal with JS Array API on the Java
side (JS Array APIs largely redundant from java developer's point of view)
I have not thought through all the details, but do see the pain if nothing
is done ... Just my 2 cents
On Thursday, June 9, 2016 at 6:26:28 AM UTC-7, Paul Stockley wrote:
>
> As Thomas says, it will be impossible to support passing any of the
> collection interfaces directly through to JS code. You might think however,
> that you could change the implementation of ArrayList to actually be a JS
> Array. I don't think this is possible either because an instance of
> ArrayList needs to fulfill the Java contract of being able to know which
> interfaces it implements. This is done by having special meta data attached
> to the object prototype. The minute you start touching the Array prototype
> you have the potential of incompatibility with existing JS code.
>
> Having said that, it is totally possible to implement an adapter to make a
> JS array look like a List. Below is a very hacky way to do it (the example
> uses the Array JsNative interface I defined but you could do the same with
> JsArray)
>
> *native *<E> List<E> asList(Array<E> a) */*-{
> **l** = @java.util.ArrayList::new()()
> **[email protected]::array <javascript:>** = a;
> return **l**;
> }-*/*;
>
> Array<String> jsArray = Array.*create*();
>
> jsArray.push(*"val1"*);
> jsArray.push(*"val2"*);
>
> List lArray = asList(jsArray);
>
>
> //Any changes to lArray will reflect in jsArray and vice versa
>
>
> lArray.add(*"val3"*);
> jsArray.push(*"val4"*);
>
>
> I strongly do not recommend using the above approach. A better way would be
> to create an adapter class that takes the native Array to wrap in the
> constructor and implements the List methods. I have implemented this in my
> library.
>
>
--
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.
